私は、Saleforce SOAP API を使用するコンソール アプリを構築してきましたが、Web アプリで Salesforce API を使用する必要があります。
Web ベースではないアプリには SOAP が適していて、Web ベースのアプリには REST が適していると考えてよろしいですか?
ローカル アプリからのレポート作成、または Web サイトから Salesforce への投稿に使用されるラッパーをどこで作成する場合、アプリが何であるかに応じて、REST API と SOAP API の両方を公開する必要がありますか? それとも、1つを使用することに固執する必要がありますか？1 つだけ選択する必要がある場合、どのような決定要因を確認する必要がありますか?
他の回答には、いくつかの優れた一般情報が含まれています。考慮すべきセールスフォース固有の事項は次のとおりです。
1）SOAP APIでデータを直接一括更新できますが、RESTからそれを行うにはAsyncBulkAPIを使用する必要があります。
2）SOAP APIには、REST APIでは利用できないものがいくつか含まれています。特に、describeLayout、queryAll、getDeleted、getUpdatedです。
3）REST APIには、おしゃべり用のAPIや、最近アクセスしたレコードリストへのアクセスなど、SOAPAPIでは利用できないものがいくつか含まれています。
4）REST APIは、base64エンコード/デコードのオーバーヘッドなしでバイナリデータ（ファイル、添付ファイル、コンテンツなど）にアクセスできます。
そのため、アプリが何をしようとしているのかによって、どちらかの方向に進む可能性があります。
Web アプリであるかどうかに関係なく、.NET アプリケーションで使用する場合は、最終的に個人の好みになると思います。
個人的には、.NET には SOAP サービスを利用する機能が多数組み込まれているため、SOAP を使用します。.NET はすべてのメソッド プロトタイプを作成し、REST 要求を自分で作成するよりも開発を高速化します。.NET が SOAP のマーシャリングを処理します。
ラッパーの構築に関しては、ターゲット オーディエンスを考慮する必要があります。ターゲット オーディエンスが他の .NET アプリケーション開発者である場合、独自の WCF サービスを公開することは適切なオプションである可能性があります。WCF には SOAP または REST のエンドポイントもあります。
私見ですが、質問が示すように.NETからソリューションを開発している場合は、SOAPが最適です。REST サービスは、SOAP に関連するバルクやツール セットの要件がなく、.NET などの多額の投資ツールにアクセスできないブートストラップ開発者に適しているため、有益です。REST は基礎となる HTTP 方法論をより厳密に反映しており、読みやすく、明示的に解析しやすいという他のコメントに同意しますが、VS や .NET などのツール内から心配する必要はありません。
さらに、ある時点で通信ミックスに組み込まれる可能性のある既存のコンソール アプリがあるため、REST の場合のように HTTP に縛られず、トランスポートに依存しない WCF の柔軟性を持たせるとよい場合があります。
したがって、REST の利点を利用したり、SOAP の欠点の影響を受けたりする立場にあるとは思えません。そのため、既存のツール セットに最適な高度に標準化されたオプションを使用することは理にかなっています。
REST または SOAP の両方が使用可能な場合にどちらを使用するかの決定は、通常、次のことに関連しています。
「ローカル」アプリがサーバー側からサービスを呼び出している場合、他のすべてが同じであれば、少なくとも WSDL から直接 C# コードを生成でき、SOAP API の使用がより簡単になります (ハンドコーディングは不要)。
Web アプリケーションがクライアント側 (ブラウザー) から API を直接呼び出す必要がある場合は、REST を使用して JSON を操作します。これははるかに簡単になります。関係なく同じラッパーを再利用することはできないため、2 つの異なる API を使用しても問題はありませんが、それらを学習するのに時間がかかります。
Web アプリで API を (クライアントではなく) サーバー側で使用する場合は、必ず 1 つの API のみをターゲットにしてください。コードを自動生成して呼び出す場合は WSDL を使用し、それ以外の場合は単純化と効率化のために REST を使用します。
IMO、SOAP はコントラクト型メッセージング アーキテクトとして作成された標準でした。つまり、メッセージを渡すときは、この「コントラクト」を使用するだけです。それは、特定のテクノロジーを取り込まないほど十分に一般的でした。
REST は HTTP を取り入れた実際の方法論であり、GET、POST、PUT、および DELETE を最大限に活用する方法です。
どちらかが優れているとは思いませんが、要するに、仕事に適したツールを使用することです。Web ベースのアプリと非 Web ベースのアプリを区別しません。SOAP または REST は両方にメリットがあるためです。
最初に回答を得るいくつかの質問を次に示し
ます。 1) ターゲット クライアントは誰ですか。Microsoft Workshop クライアント、Java、PHP タイプ。
2) Api に公開したい (適切な用語がない) 「エンドポイント」のタイプ。(JSON、XML、Ajax、POX、または上記のすべて。)
3) クライアントはこの API で何をしますか? SOAP に基づくクライアントは既にありますか。その場合は、SOAP が最適です。
4) REST は、URL の設計について考えさせ、クライアントがデータを「マッシュアップ」して必要なものを構築できるようにします。それで、それがあなたが望むものだと思うなら。REST が進むべき道です。
5) REST は HTTP の「GET」を利用します。これにより、クライアントは結果をキャッシュできます。「条件付きGETはそれが呼ばれるものです。これにより、大きなオブジェクトをキャッシュし、最後の更新がキャッシュされたものと一致するかどうかをヘッダー（小さな）を介してサーバーに問い合わせることができます。そうであれば、完全なオブジェクトGETを気にしないでください。何is cached が最新バージョンです。これは SOAP で実行できますが、すぐに使用できる REST の方が適しています。
とにかく、うまくいけば、より良いデータが得られるので、より良い決定を下すことができます. 他のすべてが失敗した場合は、両方を行うことができます。ただし、2 種類のサービス (方法論が異なる) と、両方に対応する 1 つのコードベースを取得しようとすることに対処する必要があります。（ややこしいかもしれませんが、それほど難しいことではありません。）
個人的に。私はどちらかを選び、もう一方が必要になったら、その橋を燃やして技術的負債を払います。
このパーティーに遅れましたが、簡単なメモ：
SalesforceAPIは完全にRESTfulではありません。私はそれをRESTっぽいと呼びます。いくつかのRESTインターフェースのURLにSQLのようなクエリがあります。
ソープ API:
それはなんのためですか？SOAP を使用して、組織のデータを他のアプリケーションと統合します。
いつ使用するのですか？WSDL および XML データを操作する必要がある既存のミドルウェア サービスがあります。
プロトコル SOAP/WSDL データ形式 XML 通信 同期
残りの API:
それはなんのためですか？REST を使用して組織内のオブジェクトにアクセスします。いつ使用するのですか？REST アーキテクチャを活用して、組織と統合したいと考えています。WSDL 要件はありません。ブラウザーベースのアプリケーション、モバイル アプリ、高度にインタラクティブなソーシャル アプリケーションに最適です。プロトコル REST データ形式 JSON、XML 通信 同期