ArcGIS RESTとSOAP API

とき、それは、ArcGIS Serverの使用が適切であるREST APIを対SOAPのAPIとその逆？あるものが他のものより優れているとどう思いますか？

たとえば、SOAPサービスをサービス参照として使用して、Visual Studioに統合できます。RESTとのそのレベルの統合を可能にするものはありますか？

詳細：ArcGIS GISサービス

これはいい質問です。RESTは好きですが、ジオメトリのZ値とM値を要求する方法がわかりません。これは、PointNオブジェクトを使用するSOAPで可能であるように見えます。この質問が進化してより多くの違いがリストされるのを見るのは素晴らしいことです。

もう1つの要素は、サポートする必要のあるクライアントです。Silverlightだけの場合、SOAPははるかに魅力的です。

私は、Json.NETを介して複雑なオブジェクトを送信するSOEとGPサービスを開発しました。これらのオブジェクトは、Silverlightによって簡単に消費されますが、javascriptクライアントのほうがずっと苦労するようです。

REST-代表的な状態の転送

RESTは基本的に、各一意のURLが何らかのオブジェクトの表現であることを意味します。HTTP GETを使用してそのオブジェクトのコンテンツを取得し、それを削除した後、POST、PUT、またはDELETEを使用してオブジェクトを変更できます（実際には、ほとんどのサービスがこのためにPOSTを使用します）。

SOAP-シンプルオブジェクトアクセスプロトコル

SOAPは主にエンタープライズアプリケーションに使用され、幅広いタイプを統合します。アプリケーションの別の傾向は、レガシーシステムなどと統合することです。Googleは、SOAPを使用してWebサービスを実装することに一貫性があります（Bloggerを除く）

SOAPは、ArcGIS Server +1 with KirkのGeoProcessingで勝利します

以前のクライアントでは、これを長年にわたって見てきましたが、SOAPの開発リードタイムが長すぎて、組織にとってRESTの実装は簡単だったというのが彼らにとっての長短でした。

SOAPは実際にはWebサービスでもない、と主張することができます...

ここにいくつかの引数があります：

SOAP / REST

ArcGIS REST API 10.1以降、ジョブをキャンセルしてZとMを返すことができるようになりました

GPジョブの送信（returnZおよびreturnMのオプションが追加されました）

GPジョブをキャンセル

SOAPはRESTに比べて非常に厚くて遅い一方で、使用とコーディングが非常に簡単であるため、ますます多くの人々がRESTサービスに移行しています。近い将来、私たちは大きな移行を目にし、（願わくば）SOAPは消滅するでしょう。