私はSOAPからRESTに移行していますが、これは良い動きだと同僚に納得させたいと思います。SOAPが提供できる追加のセキュリティメカニズムは必要ありません。私たちにとって、SOAPとWSDLのオーバーヘッドは、何年にもわたって頭痛の種であることが証明されています。
明らかな単純化とは別に、私たちのシステムにとって本当に価値のある利点の1つは、HTTPキャッシングメカニズムです。この件については読んだことがありますが、これらのキャッシュメカニズムをSOAPメッセージに適用できない理由をまだ完全には理解していません。
慣例により、RESTがURL内のすべてのパラメーターをエンコードしているからですか？GET呼び出しはパラメーターを持つ本体も持つことができるので、RESTに制限されていないことは理解していますが、そうするとキャッシュメカニズムが機能しませんか？
転送メカニズムとしてHTTPを使用する場合、SOAPはHTTPPOSTリクエストを介して送信されます。HTTP POSTはべき等ではないため、HTTPレベルでキャッシュされません。
問題のリクエストがべき等のリクエスト（GET、PUT、および（理論的には）DELETE）である場合、RESTはキャッシュされる可能性があります。POSTリクエストは引き続きキャッシュされません。とはいえ、これを使って多くの作業を行うことを計画している場合は、キャッシュがまだ有効かどうかをチェックする方法を調べる必要があります。特に、ETagヘッダーは、値を計算するための安価な方法があれば、キャッシュを実装するための優れた方法になります。
慣例により、RESTがURL内のすべてのパラメーターをエンコードしているからですか？GET呼び出しはパラメーターを持つ本体も持つことができるので、RESTに制限されていないことは理解していますが、そうするとキャッシュメカニズムが機能しませんか？
RESTは、URLでリクエストパラメータをエンコードする方法について特定のメカニズムを規定していません。推奨されるのは、クライアントがURL合成を行わないことです。サーバーにすべてのURL作成を行わせます（パス内への埋め込みやクエリパラメーターなど、必要なメカニズムによって）。絶対にすべきではないのは、クライアントがサーバーに本文を送信するGETを使用することです。どのキャッシュもそれを失う可能性があります。代わりに、そのリクエストがリソースの単純なフェッチに対応していない場合は、その複雑なドキュメントをサーバーにPOSTまたはPUTし、操作の結果を別のステージとして取得します。
操作の結果を別の複雑なドキュメントとして返す複雑なドキュメントのPOSTは、SOAPのエンコード方法とほぼ同じです。それをしたい場合は、SOAPを直接使用することをお勧めします。これは、多くの言語ではるかに成熟したツールを備えているためです。そのようにRESTを実行したい場合は、おそらくどこかで間違っているでしょう…</ p>
POST要求が一般にべき等ではないと述べることは正しくありません。POSTはべき等でない操作に使用する必要がありますが、SOAPは実際にはHTTPを正しく使用しておらず、その結果、そのPOSTはべき等操作に使用されます（たとえば、IDでエンティティをフェッチするために使用されます（通常は使用します）。 GET for）。
また、これによると：HTTPでPOSTメソッドをキャッシュすることは可能ですか？ （再起動の答えを確認してください）、POST要求はRFCに従ってキャッシュすることが可能です。ただし、ブラウザやプロキシではうまく実装されていない可能性があります。とにかく、適切なHTTPヘッダーを追加すれば、SOAPoverHTTPメッセージはHTTPキャッシングメカニズムを使用してキャッシュできるはずです。
もう1つの理由は、SOAP URIが常にsoapサーバーであり、キャッシュする必要のあるリソースやリソースを決定しないことである可能性があります。したがって、キャッシュサーバーは、知らないもののキャッシュを実行できません。ただし、RESTには各リソースのURIがあり（同じリソースの複数のURIにすることができます）、これはキャッシュサーバーがそのジョブを実行するのに役立ちます。
これに加えて、他の回答で述べられているように、GET、PUTなど（主にGET）などの一部のHTTP動詞のみがキャッシュに使用されます。