SOAPは何のために発明されたのですか？

この質問はこれに触発されました。SOAPを発明する最初の目標は何でしたか？古い種類のHTTPとRESTがあったときになぜ発明されたのですか？

RESTは標準ではなく、（大まかに定義された）アーキテクチャです。そしてそれはHTTPに結びついており、企業の世界の多くの人々はこれを制限と見なしていました。そのため、他の転送レイヤーでも機能する一般的な標準プロパティが必要だと考えました。

そしてbtw SOAPはRESTの前に定義されました（少なくともWikipediaによれば:-)

SOAPは、プレーンなHTTPよりも複雑なデータ構造の交換に適しています。RESTは設計上、実質的にCRUD操作に制限されていますが、SOAPは任意のメソッド呼び出しを許可しますが、これはRESTスキームに押し込むことができない場合があります。

ウィキペディアから：

SOAPは、当初はSimple Object Access Protocolとして定義されていましたが、コンピュータネットワークでのWebサービスの実装において構造化された情報を交換するためのプロトコル仕様です。... SOAPには3つの主要な特徴があります。拡張性（セキュリティとWS-ルーティングは開発中の拡張機能の1つです）、中立性（SOAPはHTTP、SMTP、さらにはTCPなどのトランスポートプロトコルで使用できます）、および独立性（SOAPでは任意のプログラミングモデル）。

SOAPはHTTPに限定されず、すぐに使用できるセキュリティを提供します。

HTTPを使用していて、セキュリティが必要ない場合（Webサービスが公開されている場合）、SOAPは必要ありません。

私は部屋にいませんでしたが、90年代半ばから後半に存在した他のRPCオプションに対するSOAPは非常に優れたアイデアであり、非常に合理的な対応でした。CORBAのように、私が個人的に対処しなければならなかったとは言えない獣ですが、単に言及しただけで、成長した男性が自分自身を汚してしまう可能性があります。多くの場合、CORBA以外のオプションはより恐ろしいものであり、標準化はほとんど行われず、多くのカスタムメッセージングプロトコルが実行されていました。統合システムは非常に大変なものでした。トランスポートとしてHTTPに依存しない正当な理由がありました。90年代後半、一般的なLAN速度は10メガビット以下でしたが、WAN速度はしばしばボーで測定されました。RESTに多くの機能を果たすエッジキャッシングインフラストラクチャ全体は存在しませんでした。

これでSOAPが実現します-それ自体はトランスポートメディアを指定していません。誰かがなんとかして鳩を介してSOAPコールを実装できたと思います。または、おそらくアフリカのツバメ。いずれにせよ、メッセージングオプションの実装は、以前よりもはるかに簡単です。まともなSOAPツールキットがあれば、これまでにない他のどのツールよりもはるかに簡単に使用できます。そして、ツールを簡単に作成できます。非常に簡単なので、プロトコルを拡張する必要があると考えました。そして、そこがWS- *の出番です。車輪がそのトラックから落ちたところです。。。

SOAPは、他のメッセージングプロトコルが作成されたのと同じ理由で作成されたメッセージングプロトコルです。オブジェクト情報の受け渡し方法を標準化します。ウィキペディアのページに記載されているように、このページはMicrosoftで作成されたものであり、現在はW3Cによって維持されているオープンスタンダードです。

より良い質問は、なぜSOAPかXML風味のスキームかJSONか何を選択するかであり、答えは特定の状況で最も簡単/最も実用的なものを使用することになります。

私の意見では、SOAPはRPCの別の見方です。最近、WebServiceをどのように公開しているのか見てみましょう。一方がWebServiceとしてメソッドをマークし、もう一方がWSDLをフェッチして、ローカルであるかのようにリモートメソッドを使用します。私はすべてのSOAP問題をかなり認識していますが、ある程度の抽象化では、SOAP / WSはRPCの約束を果たします。もちろん、RESTアーキテクチャーに基づくAPIを思い付くことができますが、RPC定義に何らかの形で反抗するいくつかのビットをコーディングする他の当事者が依然として必要です。