WebサービスにSOAPを使用する理由は何ですか? 質問する

Web サービスを構築する場合、次の 2 つの方法があります。

• 石鹸
• 休む

ほとんどの人は抵抗の少ない道を選びます。休むこれは、シンプルさ、開発の容易さ、HTTP を本来の用途どおりに使用すること、キャッシュ プロキシを有効に活用すること、より人間が読みやすい結果などを意味します。

石鹸一方、RESTよりも重量級であり、大規模な仕様しかし、SOAP はより複雑なため (SOAP は以前は Simple Object Access Protocol の略語でしたが、実際はそうではありませんでした)、多くの人に好まれていません。

どちらのアプローチも機能し、どちらにも長所と短所があります。

たとえば、SOAP は HTTP(S) だけでなく任意のトランスポート プロトコルを使用でき、セキュリティに関するオプションが多く、信頼性の高いメッセージングなどが提供されます。一方、REST はさまざまな種類のデータ形式を許可し、JSON 形式によりブラウザーのサポートが向上し、パフォーマンスも向上します。

SOAPとRESTの比較はWeb上でたくさん見つかるので、これ以上詳しく説明するつもりはありません。私が強調したいのは、場合によってはどちらかが他方よりもうまく機能するという事実です。あなたの特定のケースに応じて、どれを実装するかを決定し選択するのはあなた次第です。。

編集：あなたの質問に答えます:

なぜ SOAP や REST を使用するのでしょうか? それらなしでも Web サービスを利用できるのではないでしょうか?

さて、W3Cではウェブサービスを次のように定義しています。ネットワーク上で相互運用可能なマシン間の相互作用をサポートするように設計されたソフトウェア システム「」。

OK...定義としてはいいです。しかしこれはSOAP/RESTの定義ではありません。この要件は、通信プロトコル処理する。

つまり、基本的に、"相互運用可能なマシン間インタラクション" をサポートしている限り、任意の通信プロトコル (独自のプロトコルを作成することもできます) を使用して Web サービスを利用できます。これは、SOAP や REST 以外のものも意味します (わかりました... REST はプロトコルではありません。ここでは、自分の主張を証明するために参照として使用しているだけです... 我慢してください)。

しかし、ウェブサービスを作成する理由は顧客にサービスを利用してもらいたいそして、あなたのクライアントは荒野の西部 (つまり Web :D) にいて、そこの人々は SOAP/REST を話します。そこであなたはこう言います。「当店ではSOAPやRESTは好きではありません。RPC、CORBA、そして弊社独自の「Bone Crusher 10000」プロトコルのようなものを好みます。弊社と取引をしたいなら、「Bone Crusher 10000」を学んでください。「そしてあなたの顧客はこう言うでしょう（眉を上げながら）」そうだよね……「」。

(ここでは、あなたのプロトコルが SOAP/REST を完全に凌駕するような画期的なものではないと想定しています :D)

したがって、SOAP/RESTを使用しないと、ターゲットオーディエンスが制限されます。たとえば、英語のようなものです。私は英語のネイティブスピーカーではありませんが、あなたはどうですか？まあ、英語でコミュニケーションが取れるので、それはあまり問題ではありません。これを試してみませんか？アイスランド語? アイスランド語を勉強している間待ってくれますか、アイスランド語も私の母国語ではないので。

すでに述べたように、あなたの特定のケースに応じて何を実装するかを決定し選択するのはあなた次第ですしかし、既知のテクノロジー スタックから離れると、それに付随するものも捨ててしまいます。豊富な経験、リソース、ツール、コミュニケーションオプション。

最後に、SOAPプロトコルは現在多くのサポートがあり、WSDLファイルから簡単にクライアントを生成できます。プレスト...クライアントがWebサービスと通信できるようになります。「Bone Crusher 10000」では、これほど簡単にできるでしょうか？ツールを書いて、リソースやサポートなどを提供すれば、もちろんできます！しかし、それを実現するには時間とお金がかかります。すでに発明されており、現在広く使用されている。