私はSaleforce SOAP APIを使用するコンソールアプリケーションを構築しており、現在はWebアプリケーションでSalesforce APIを使用する必要があります。Salesforce SOAP対REST
SOAPはWebベース以外のアプリケーションに適しており、RESTはWebアプリケーションに適していると仮定していますか？
ローカルアプリケーションからのレポート作成や、私たちのウェブサイトからのsalesforceへの投稿に使用されるラッパーを作成する場所は、アプリケーションの種類によってREST APIとSOAP APIの両方を公開する必要がありますか？それとも、私はそれを使うことに固執すべきですか？何かを選ぶ必要がある場合、私は見なければならない決定要因は何ですか？
他の答えはいくつかの良い一般的な情報が含まれている、考慮すべきいくつかのSalesforce特定の事柄が
1です）あなたはSOAP APIの直接一括更新データをすることができますが、非同期バルクAPIを使用する必要がありますそれをRESTから行うこと。
2）石鹸APIはREST APIを含む、SOAP APIで利用できないいくつかのことが含まれているREST APIで利用できるいくつかのことではない、最も顕著なのdescribeLayout、queryAll、getDeleted & getUpdated
3）が含まれていチャタリング用のAPI、最近アクセスしたレコードリストへのアクセスなどがあります。
4）REST APIは、base64エンコーディング/デコードのオーバーヘッドなしにバイナリデータ（ファイル、添付ファイル、コンテンツなど）にアクセスできます。
あなたのアプリが何をしようとしているかによって、どちらか一方の方法であなたを押し込む可能性があります。このパーティーに後期
私は、それがWebアプリケーションであるかどうかに関わらず、.NETアプリケーションで消費すると個人的な好みになると思います。
個人的には、.NETにはSOAPサービスを使用するための機能が多数組み込まれているため、SOAPを使用します。すべてのメソッドプロトタイプを作成し、REST要求を手作業で作成するよりも速く開発します。 .NETはSOAPのマーシャリングを処理します。ターゲットオーディエンスが他の.NETアプリケーションの開発者であれば
ラッパーを構築するため、あなたがあなたターゲットオーディエンスを考慮しなければならないとして、その後、独自のWCFサービスをさらすことはまともな選択肢かもしれないが、WCFは、SOAPのいずれかのためのエンドポイントを持っていますまたはREST。
RESTまたは両方が利用可能なSOAPを使用する決定は通常に関連している：あなたはあなたのアプリケーションのために使用している
「ローカル」アプリケーションがサーバ側からサービスを呼び出している場合は、それ以外はすべて等しいUはWSDLから直接C＃コードを生成することができ、SOAP APIをより簡単に使用できます（ハンドコーディングなし）。
Webアプリケーションがクライアント側（ブラウザ）から直接APIを呼び出す必要がある場合は、RESTを使用してJSONを使用します。これははるかに簡単になります。それと同じラッパーを再利用することはできないので、2つの異なるAPIを使用して学習する時間以外に問題はありません。
APIのWebアプリケーションの使用がサーバー側（クライアント側ではない）の場合は、1つのAPIのみを対象にしてください。 WSDLを呼び出してコードを自動生成したい場合はREST、それ以外の場合は簡潔で効率的です。
IMO、SOAPは契約タイプのメッセージングアーキテクトとして作成された標準です。メッセージを渡すときには、この「契約」を使用するだけです。特定の技術を採用していないほど一般的でした。
RESTはHTTPを取り入れた実際の方法であり、GET、POST、PUT、DELETEを最大限活用する方法です。
私は、どちらかというともう一方の方が優れているとは思いません。実際には、仕事に適したツールを使用しています。私はWebベースのアプリケーションとWebベースではないことを区別しません。 SOAPまたはRESTは両方に有益な可能性があるためです。
ここに私が最初に答えられるいくつかの質問があります：
1）私のターゲットクライアントは誰ですか？ Microsoft Workshop Client、Java、PHPタイプ。
2）どのようなタイプの（より良い用語の欠如）「エンドポイント」は私のApiに公開したいのですか？ （JSON、XML、Ajax、POXなど）
3）クライアントはこのAPIをどのように使用しますか？彼らはすでにSOAPに基づいたクライアントを持っていますか？そうであれば、SOAPは道のりです。
4）RESTはあなたのURLデザインを考え、クライアントがデータをマッシュアップして必要なものを構築できるようにします。だからあなたはそれがあなたが望むものだと思うならば。 RESTは道のりです。
5）RESTはHTTPで "GET"を使用します。これにより、クライアントは結果をキャッシュできます。 "条件付きGETは、それが呼び出されたものです。大きなオブジェクトをキャッシュすることができます。最後の更新がキャッシュされているものと一致する場合は、ヘッダ（小）を介してサーバに問い合わせます。
とにかく、より良いデータが得られますので、より良い決定を下すことができます。それ以外はすべて失敗しますが、2つのタイプのサービス（さまざまな方法論）と1つのコードベース（両方とも難しいことはありますが難しくありません）に対処する必要があります。
個人的には、私は1つを選択し、次に他のものが必要な場合は、そのブリッジを焼いてそれに対する技術的負債を支払う。
IMHO、質問からわかるように.NETからソリューションを開発する場合は、SOAPが必要です。 RESTサービスは、SOAPを取り囲むバルクとツールセットの要件が不足しているため、.NETなどの大規模な投資ツールにアクセスできないブートストラップ開発者にとって有益です。私は、RESTが根底にあるHTTPの方法論をより密接に反映し、明示的に読みやすく解析することができるという他のコメントに同意しますが、これはVSや.NETなどのツールの中で心配する必要はありません。
さらに、ある時点でコミュニケーションミックスに持ち込まれる可能性のあるコンソールアプリケーションがあるため、WCFに柔軟性を持たせ、RESTの場合と同様にHTTPに縛られないようにするとよいでしょう。
RESTのメリットを活用したり、SOAPの欠点の影響を受ける立場にはないと思いますので、既存のツールに最も適した高度に標準化されたオプションを使用することは理にかなっていますセット。
が、ちょうど簡単なメモ：
SalesforceのAPIは完全にRESTfulではない：私はRESTっぽいそれを呼び出します。それは、そのようなことのような、そのRESTインターフェースのために、URLの中でSQLのようなクエリを持っています。
のSOAP API：
それは何ですか？ SOAPを使用して組織のデータを他のアプリケーションと統合する。
いつ使用しますか？ WSDLとXMLデータを処理する必要のある既存のミドルウェアサービスがあります。
プロトコルSOAP/WSDL データ形式のXML コミュニケーション同期
のREST API：
それは何ですか？ RESTを使用して組織内のオブジェクトにアクセスする。 いつ使用しますか？組織との統合にRESTアーキテクチャを活用したいと考えています。 WSDL要件はありません。 ブラウザベースのアプリケーション、モバイルアプリケーション、高度にインタラクティブなソーシャルアプリケーションに適しています。 プロトコルREST データ形式JSON、XML 通信同期
ポイント2では、REST APIにこれらのエンドポイントが含まれていないことは間違いありません。たとえば、あなたは削除することができます：http://www.salesforce.com/us/developer/docs/api_rest/Content/dome_get_deleted.htm – joshdick