SOAPはRESTより意味があるのはいつですか？
RESTについての私の理解から、暗黙の仮定はすべての操作がCRUD操作であるということです。 CRUD操作を行わず、より複雑なロジックを実行している場合があります。この場合、SOAP=より適切ではありませんか？それとも、一連のCRUD操作がどれほど複雑であっても、すべての操作が一連の小さなCRUD操作に分割される必要がある場合です次から次へと呼び出されますか？しかし、これはあなたが書こうとしている操作をより面倒にしませんか？RESTの代わりにSOAP= 。
私はこれから始めます：私はSOAPよりもRESTを好みます。 RESTには、適切に実行すると、配布可能性、応答のキャッシュ可能性、明確に定義されたセマンティクス、ブラウザーで直接使用できる機能など、いくつかの大きな利点があります。ただし、私は自分自身に対して議論するのが好きなので、次のプロジェクトでSOAPを使用する必要があるのはこのためです。これらのポイントの多くは REST実践中 から来ています。REST-yプロジェクトを開始するときに全員が自分の机の上に置く必要があります。
SOAPはどこにでもあります
00年代には、SOAPは、CORBA、DCOM、RMIなどの相互運用できない多数のテクノロジーに取って代わりました。そのヴィンテージのシステムと統合する必要があるレガシーシステムがある場合、それはSOAPを話す可能性があり、喜んでWSDLを消費します。考えられるすべての言語には、WSDLをドメインオブジェクトに解析するツールがあり、多くの開発者がそれを使用する方法を知っています。 RESTについては、必ずしもそうであるとは限りません。 できます（ApacheのHTTPコンポーネントのように）HTTPクライアントライブラリを介してRESTサービスと直接やり取りするという苦労も伴います。 RESTのツールサポートが向上しています。最新のJAX-RS 2.0には、かなり使いやすい標準クライアントがあります。
SOAPのSはSimpleの略です
これが SOAP 1.1の仕様 です。それは短く、SOAPメッセージがどのように見えるかを非常に明確に概説しています。仕様の多くはIMOの難解なケースに特化しています（たとえば、10年以内に部分的に送信されたアレイを使用したことはありません）が、その主な内容は、エンベロープ、ヘッダー、ボディです。 SOAPメッセージがHTTPを介して送信される場合、ヘッダーとエンベロープは冗長であると認めますが、SOAPは任意のメディアを介して送信できるため（別の回答で言及）、それは必要悪。 SOAPメッセージを簡単に見ることができ、メッセージを書くための特別なソフトウェアも必要ありません。
WS- *拡張により機能が追加されます
RESTフルWebサービスには、組み込みのトランザクションサポートはありません。トランザクションRESTサービスを作成することは可能ですが、yourトランザクションシステムのセマンティクスは、myトランザクションシステムのセマンティクスとは異なる場合があります。 SOAPには、トランザクションの一貫性のための明確なワークフローとメカニズムを定義するWS-Transactionsなどの拡張機能があります。同様に、WS-AddressingやWS-Securityなどの他の拡張機能は、メッセージのルーティングとメッセージの認証/暗号化を記述します。 RESTでメッセージ認証を行うには、クライアント側のSSLを使用するか、独自にロールする必要があります。
SOAPでは、ドメイン操作をCRUDにマップする必要はありません。
RESTはCRUDについてすべてではありませんではありませんが、非CRUD操作を実行するには、それらをリソースにマップする必要があります。これは必ずしも悪いことではありませんが、設計者にいくつかの問題を引き起こす可能性があります。 「本をチェックアウトする」などの動詞操作をHTTP動詞の1つにマッピングするには、PATCHリクエストでisCheckedOutフラグをbookに設定します。新しい_/checkout_リソース、または他の任意の数のリソースを作成している可能性があります。 SOAPy Webサービスと、WSDLから自動生成されたコードを使用すると、単純にservice.checkOut(book, patron)を実行できます。その意図は非常に明確です。
SOAPの障害メカニズムは、より豊富な障害処理を促進します
OK、それで完璧ではありません、そしてほとんどのSOAP Webサービスは正しく行いませんが、それはSOAPのせいではありません。 SOAPには、例外（フォールト）、つまり実際のオブジェクトに対する組み込みサポートがあります。何が問題であったのか、どのように修正するのかについての詳細を含めることができます。 RESTがHTTPステータスコードを使用することは、この点で非常に便利です。これは、開発者が400、403、500などを送り返す必要があるかどうかを考え、開発者がこれらのコードに標準的な意味があるためです。ただし、メッセージ本文に標準はありません。また、my-crappy-REST-serviceがエラー本文を含む_200 OK_応答を返送しないようにするRESTメカニズムはありません。 RESTサービスの場合と同様に、SOAPサービスも役に立たない応答を生成するのは簡単です。
私の経験
これらは、次のプロジェクトでSOAPをRESTよりも使用する大きな理由ではないかもしれませんが、自分自身を説得したいと思っていました。
現在、REST APIを公開し、SOAP APIを使用するプロジェクトに取り組んでいるので、両方の世界で最高/最悪です。私は嫌いです SOAPのものですが、それは主に、私が使用しているバックエンドシステムに改善の余地があるためです。 JAX-RSは本当に素晴らしいサーバーサイドREST APIであり、ほとんど痛みはありません。 RESTのため、そして REST制約 に固執するために私たちは本当に厳しいので、うまくいけば、ユーザーエクスペリエンスを向上させるインフラストラクチャでHTTPキャッシングを活用しています。ただし、ではありませんですが、アプリケーションでHATEOASサービスを完全に必要としないためです。私たちのサービスもその性質上、主にCRUDであるため、名詞 a 動詞の方法について難しい決定をする必要はありません。
要するに、私はSOAPが常に悪い選択ではないことを推測しますが、大きなSOAPインフラストラクチャがすでにない限り、多くのことは可能ではありません。
RESTは、自己完結型オブジェクト、または最悪の場合、密結合オブジェクト階層でCRUD操作を実行するという考えに基づいて構築されています。
SOAPはこれよりも構造化されていないため、より流動的な構造を持つトランザクションに適しています。 SOAPリクエストとレスポンスは、WSDLに準拠する必要がある限り、定義された構造を持っていますが、オプションの要素、繰り返し要素、複雑な要素などのための多くの余地を残しています。
RESTはCRUDのように見えるかもしれませんが、リソース指向アーキテクチャーでは、複雑なケースを処理できます。
たとえば、クレジットカードに請求したい場合、それは動詞のように見え、CRUDに適合しない可能性がありますが、Purchaseリソースを使用できない理由はありません。次に、Purchase POSTの場合、サービスは実際に舞台裏でクレジットカードに請求できます。
RESTについての私の理解から、暗黙の前提はすべての操作がCRUD操作であるということです。
確かに違います。特定のREST Webサービスツールキットのエクスペリエンスについて言及しているかもしれませんが、一般にそのような制限はありません。RESTは、ドキュメント、表現の交換に関するものです状態の。
実際、RESTは非常に柔軟なので、ドキュメント内の複雑なロジック全体をPOSTから/transactions URL、返された/transactions/<id>実行を監視し、結果を取得します。このようなRESTのショットガンアプリケーションが有用かどうかは、別の問題であり、アプリケーションの設計に依存します。
SOAP/WSDLの組み合わせは、厳格なWebインターフェイスコントラクトが必要な場合に使用できます。これは、一部のビジネスシナリオで正当化できるケースです。 SOAPはRESTで使用できますが、SOAP/RESTの組み合わせはそのサポーターを見つけることができませんでした。おそらくそれが一般的なRESTアーキテクチャに値を追加しないためです。I個人的に使用する場合は、互換性/レガシーの理由でSOAPを使用するか、グリッドコンピューティングを行っていたときのWS- *全体の一部として使用する。
すでにここにあるすばらしい反応に加えて、もう1つの理由は、あなたが誰と通信しているのか、またはどの言語で開発しているのかです。
一部のアプリケーションは、SOAPまたはRESTインターフェースのみを備えています。他の場合では、プログラミング言語は、（設計または単なる慣例により）1つのプロトコルを他より優先します。
例えば。 Ruby on Railsは、RESTをサポートしており、多くのリソースの助けが必要な場合、 RailsにはSOAP=を実行するためのモジュールがありますが、それらは十分にサポートされていないため、さらに困難になる可能性があります。さらに、Rails RESTを使用することであり、アプリがサポートしていない場合、Rails開発者が使用することはできません。そうしないと、開発者が大声で不満を言うでしょう。
一方、マイクロソフトはSOAPの大きな支持者であり、私はC＃や.NETのプログラマーではありませんが、SOAP =とても良いです。Javaについても同じことが言えます。SOAPの方が、RESTの場合よりもサポートされています。
以上のことから、上記の例はいずれも不可能ではありません。言語を使用するプログラマの文化または言語自体がどちらかを好む傾向があるということだけです。あなたはあなたの決定をするときそれを考慮に入れるべきです。
Microsoftスタックとのやり取りのみを計画していて、大規模な帯域幅の消費が問題にならない場合は、SOAPの方が適しています。
それ以外の場合、Microsoft以外のユーザーにSOAPのみのAPIを提供することは一般に失礼と見なされ、どこかに独裁的な状態があり、死刑を宣告されているはずです。
石鹸は、.netに固執すること、およびコンシューマーが.NETに固執することがわかっている場合、休息よりも意味があります。
SOAPとVisual Studioの統合により、接続を簡単にすることができるので、私はこれを言います。
。NETアリーナの外に出て、残りのサービスに接続することは、他のどの言語にとっても簡単なことです。
プロバイダーとして.NETを使用する必要があり、コンシューマーにrest likeインターフェイスを提供する場合は、ASP.NET MVCを使用します。それ以外の場合は、WebAPIを使用します。 （MVCではSOAPと同様の複雑な動作が可能です。入力と出力を明確に文書化してください）
SOAPは、クライアントが簡単にアクセスできる明確な契約（WSDL）を提供します。適切なテクノロジーがあれば、サービスのネイティブAPIを非常に簡単に生成できます。
このコントラクトは、クライアントがテスト目的でサービスの偽の実装を作成する場合にも役立ちます。
> When does SOAP make more sense than REST?
石鹸を使用すると、相互運用性の標準がさらに向上します WS-* とりわけ、 XML_Signature および XML_Encryption をカバーします
理論的にはSOAPはhttp（s）に制限されていません。また、ftp、電子メールを介して使用することもできます。..ただし、SOAP http以外。
石鹸と休息のどちらかを選択できる場合は、常に休息を優先します。
本で読んだことを覚えています。
1）SOAPは構造を課します
2）石鹸の使用はより安全です
3）複雑な構造を処理できます。オブジェクトを渡します。
RESTは、小さなアプリケーションの場合に優れた解決策になると思います。Androidは、石鹸ではなくRestを使用してきましたが、軽量であるためと思います。