SOAPの消費にはSOAPスタックが必要であることがわかります。したがって、クライアントは消費するのが難しくなります。つまり、POSTデータとヘッダーを正しくフォーマットしてから、データ構造ですが、RESTではクエリ文字列の引数を使用してHTTP GETリクエストを作成し、おそらくXMLであると思われるテキストを取得します。
それでは、SOAPの余分なオーバーヘッド/複雑さは何をあなたに与えますか、いつそれを必要としますか？
SOAPの消費にはSOAPスタックが必要であることがわかります。したがって、クライアントは消費するのが難しくなります。つまり、POSTデータとヘッダーを正しくフォーマットしてから、データ構造ですが、RESTではクエリ文字列の引数を使用してHTTP GETリクエストを作成し、おそらくXMLであると思われるテキストを取得します。
それでは、SOAPの余分なオーバーヘッド/複雑さは何をあなたに与えますか、いつそれを必要としますか？
回答:
以前にREST APIを実装したことがあり、本当に気に入っています。一般に、REST over SOAP を実装する場合、クライアント/サーバーはより直交的であるため、クライアントに影響を与えることなく、サーバーをより自由に変更できます。この直交性は、HTTP動詞を介した、より抽象的で既に十分に定義された通信を使用しているためです。また、REST応答に埋め込まれたハイパーリンクを使用すると、APIを比較的簡単に拡張および拡張できます。クライアントは、これらの埋め込まれたリンクをたどって、人間がWebページ上のリンクをたどって詳細を「ドリルダウン」するような新しいリソースにアクセスすることになっています。
そうは言っても、SOAPを使用しなければならないと言われた同僚が何人かいて、いつもSOAPについて不満を言っていました。それで、私はこの2つをもう少し詳しく調べに行きました。
一般的に私が見つけたのは、何百、何千、何百万のクライアントがいるときに、RESTが高度に分散したアプリケーションに適しているということです。1つの理由は上記の直交性であり、もう1つはHTTPを使用しているため無料で取得できるキャッシュです。
SOAPは、クライアント用に小さなAPIをすばやく必要とし、スケーラビリティについてあまり心配していない場合に、より迅速に実行できる方法です。リソースを中心に構造化されたアーキテクチャがない場合も、RESTを実装できるようにアプリを再構築するのに時間がかかる可能性があるため、より適している場合があります。
些細な点かもしれませんが、RESTは完全にHTTPに基づいています。
SOAPはHTTPを必要とせず、好きなトランスポートを自由に使用できます。
SOAPメッセージは非同期かつ確実にルーティングできますが、RESTはほぼ同期パラダイムです。
RESTは、送信および受信するデータがどのように見えるかについては何も伝えません。WADLがありますが、ほとんどの場合、APIのドキュメントが正しいことに依存しています。SOAPには、データ記述にエラーが発生しにくいようにするためのXMLテクノロジーのサーカスがあります。WSDL、スキーマ...
結局のところ、RESTは基本的にHTTPに基づいたファイルシステムを取得します。あなたのシステムがそのパラダイムに適合することができるなら、それは良い選択かもしれません。
それでは、SOAPの余分なオーバーヘッド/複雑さは何をあなたに与えますか、いつそれを必要としますか？
2つの間の最大の違いは、RESTはステートレスであると想定されているのに対し、SOAPはそうではないことです。実際には、多くのREST実装は、OAuthのようなものを介して、セッションの状態を実際に実装します。
もう1つの違いは、RESTは非常に「リソース」または名詞指向です。CRUD操作を介してリソースと対話します。このパラダイムに合わないものはすべて面倒で扱いにくいものになります。
一方、SOAPはRPC（リモートプロシージャコール）プロトコルです。パラダイムではなく、単なるトランスポート層です。
RESTもポストを使用します。事実上、RESTを使用する場合、http動詞はどの操作が行われているかを示します。
RESTとSOAPは、インターネット経由でデータを渡すための異なる標準です。
両方を使用した場合、Webサービスを使用する人が.netとVisual Studioを使用していることがわかっていない限り、SOAPではなくRESTを使用することをお勧めします。通常、SOAPを使用するときにほとんどの作業を行う.net VSを除き、REST Webサービスを使用する方がはるかに簡単です。
アプリケーションの要件に対してSOAPとRESTを測定するのに役立つシンプルで視覚的なガイドが必要な場合...
Vijay Prasad Guptaは、シンプルで役立つフローチャートをまとめました。
フローチャートへの直接リンク：https : //drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
記事へのリンク：https : //www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs
今は2015年です。SOAPがもう死んでしまうことを期待していましたが、それでも悪臭のように残ります。最も基本的な「サンプル」アプリケーション以外の場合、SOAPサービスとの統合には課題が伴います。複雑なアーキテクチャであり、複数のレベルで多くのオプションがあり、複数の実装の癖と微妙な（それほど微妙ではない）非互換性が組み合わされています。私は一度も良い経験をしたことがありません。一方、RESTは簡単です。誰もがHTTPを理解しています。ほとんどの場合、JSONにはXML InfoSetよりも多くのユーティリティがあります。
SOAPの複雑さを理解するには、SOAPライブラリをプロジェクトに統合してみてください。Javaの場合、最も単純なApache Axis2クライアント（単純なADBデータバインディングを使用）は23個の新しいJARを取り込みます。23！ライブラリの膨張20MB。CXFも同様です。最後にカウントしたときの21個のJAR。
本当にしたい場合は、単純なHTTPライブラリでRESTを実行できます。