誰かがRESTとSOAPを分かりやすい英語で説明できますか？そして、Webサービスはどのように機能しますか？

SOAPとRESTに関する簡単な説明

SOAP-「シンプルオブジェクトアクセスプロトコル」

SOAPは、メッセージまたは少量の情報をインターネット経由で転送する方法です。SOAPメッセージはXMLでフォーマットされ、通常はHTTP（ハイパーテキスト転送プロトコル）を使用して送信されます。

残り-表現状態の転送

Restはクライアントとサーバー間でデータを送受信する簡単な方法であり、あまり多くの標準が定義されていません。JSON、XML、またはプレーンテキストとしてデータを送受信できます。SOAPに比べて軽量です。

どちらの方法も、多くの大手プレーヤーが使用しています。それは好みの問題です。使いやすく理解しやすいRESTが好みです。

シンプルオブジェクトアクセスプロトコル（SOAP）：

• SOAPは、HTTPまたは場合によってはTCP / IPの上にXMLプロトコルを構築します。
• SOAPは、関数とデータのタイプを記述します。
• SOAPはXML-RPCの後継であり、非常に似ていますが、通信の標準的な方法を記述します。
• いくつかのプログラミング言語はSOAPをネイティブでサポートしており、通常はWebサービスのURLをフィードし、特定のコードを必要とせずにWebサービス関数を呼び出すことができます。
• 送信されるバイナリデータは、最初にbase64エンコードなどの形式にエンコードする必要があります。
• これに関連するいくつかのプロトコルとテクノロジーがあります：WSDL、XSD、SOAP、WS-Addressing

表現状態転送（REST）：

• RESTはHTTP経由である必要はありませんが、以下の私のポイントのほとんどはHTTPバイアスがあります。
• RESTは非常に軽量です。ちょっと待ってください。SOAPが作成したこの複雑さのすべては必要ありません。
• 通常、すべてを記述する大きなXML形式ではなく、通常のHTTPメソッドを使用します。たとえば、リソースを取得するにはHTTP GETを使用し、リソースをサーバーに配置するにはHTTP PUTを使用します。サーバー上のリソースを削除するには、HTTP DELETEを使用します。
• RESTは、HTTP GET、POST、およびPUTメソッドを使用してサーバー上のリソースを更新するという点で非常に単純です。
• RESTは通常、リソース指向アーキテクチャー（ROA）で使用するのが最適です。この考え方では、すべてがリソースであり、これらのリソースを操作します。
• プログラミング言語にHTTPライブラリがあり、ほとんどのライブラリにある限り、REST HTTPプロトコルを非常に簡単に使用できます。
• バイナリデータまたはバイナリリソースは、要求に応じて簡単に配信できます。

GoogleでのRESTとSOAPに関する議論は無限です。

私のお気に入りはこれです。2013年11月27日更新：Paul Prescodのサイトがオフラインになり、この記事は利用できなくなりました。コピーはWayback MachineまたはCiteSeerXの PDFとして入手できます。

残り

RESTの主な考え方は非常に単純であることを理解しています。私たちは何年もウェブブラウザを使用しており、ウェブサイトがいかに簡単で、柔軟性があり、パフォーマンスが良いかなどを見てきました。HTMLサイトは、ユーザーインタラクションの主要な手段としてハイパーリンクとフォームを使用します。彼らの主な目標は、クライアントが私たちが現在の状態で使用できるリンクのみを知ることを可能にすることです。そしてRESTは単に、「アプリケーションを通じて人間のクライアントではなくコンピューターを駆動するために同じ原則を使用しないのはなぜですか」と述べています。これをWWWインフラストラクチャの能力と組み合わせると、優れた分散アプリケーションを構築するためのキラーツールが手に入ります。

別の可能な説明は、数学的に考えている人々のためのものです。各アプリケーションは基本的にはステートマシンであり、ビジネスロジックアクションは状態遷移です。RESTの考え方は、各遷移をリソースへの要求にマッピングし、現在の状態で使用可能な遷移を表すリンクをクライアントに提供することです。したがって、それは表現とリンクを介して状態機械をモデル化します。これが、REpresentational State Transferと呼ばれる理由です。

すべての回答がメッセージ形式またはHTTP動詞の使用法に焦点を当てているように見えるのは驚くべきことです。実際、メッセージ形式はまったく関係ありません。RESTは、サービス開発者が文書化したものであれば、どの形式でも使用できます。HTTP動詞はサービスをCRUDサービスにするだけで、まだRESTfulにはなりません。実際にサービスをRESTサービスに変えるのは、データとともにサーバー応答に埋め込まれたハイパーリンク（別名ハイパーメディアコントロール）であり、その量は、クライアントがこれらのリンクから次のアクションを選択するのに十分でなければなりません。

残念ながら、Roy Fieldingの論文を除いて、Web上のRESTに関する正しい情報を見つけることはかなり困難です。（RESTを派生させたのは彼です）。SOAPからRESTに進化する方法に関する包括的なステップバイステップのチュートリアルを提供しているため、「REST in Practice」の本をお勧めします。

石鹸

これは、RPC（リモートプロシージャコール）アーキテクチャスタイルの可能な形式の1つです。本質的には、クライアントがローカルメソッドを呼び出しているかのように、サービス境界（ネットワーク、プロセスなど）を介してクライアントがサーバーのメソッドを呼び出すことができるテクノロジーにすぎません。もちろん、実際にはローカルメソッドの呼び出しとは速度や信頼性などが異なりますが、考え方はそれほど単純です。

比較した

トランスポートプロトコル、メッセージフォーマット、xsd、wsdlなどの詳細は、RPCの形式とRESTを比較する際には重要ではありません。主な違いは、RPCサービスはRPC APIで独自のアプリケーションプロトコルを設計することによって、自転車だけを再発明することです。したがって、すべてのクライアントはサービスを使用する前にこのプロトコルを理解する必要があり、すべての要求の独自のセマンティクスのため、キャッシュなどの一般的なインフラストラクチャを構築できません。さらに、RPC APIは現在の状態で許可されるアクションを提案しません。これは、追加のドキュメントから派生する必要があります。一方、RESTは、さまざまなクライアントがAPIのセマンティクスをある程度理解できるように統一されたインターフェイスを使用し、ハイパーメディアコントロール（リンク）を使用して、各状態で使用可能なオプションを強調表示することを意味します。したがって、

ある意味では、SOAP（他のRPCと同様）は、サービスの境界をトンネリングして、接続メディアをメッセージのみを送信できるブラックボックスとして扱う試みです。RESTは、Webが巨大な分散情報システムであることを認め、世界をそのまま受け入れ、それと戦うのではなく、それを習得することを決定するものです。

SOAPは、サーバーとクライアントの両方を制御する場合、および対話が複雑すぎない場合に、内部ネットワークAPIに最適であると思われます。開発者がそれを使用するほうが自然です。ただし、多くの独立した関係者が使用するパブリックAPIの場合、複雑で大きいため、RESTの方が適しています。しかし、この最後の比較は非常にあいまいです。

更新

私の経験では、REST開発はSOAPよりも難しいことが予想外に示されています。少なくとも.NETでは。ASP.NET Web APIのような優れたフレームワークはありますが、クライアント側のプロキシを自動的に生成するツールはありません。「Webサービス参照の追加」や「WCFサービス参照の追加」のようなものはありません。すべてのシリアル化とサービスクエリコードを手動で記述する必要があります。そして、これは定型的なコードがたくさんあります。REST開発には、各開発プラットフォームのWSDLとツールの実装に似たものが必要だと思います。実際、WADLかWSDL 2.0のどちらかが適切であるように見えますが、どちらの標準も十分にサポートされているようには見えません。

更新（2016年1月）

REST APIを定義するためのさまざまなツールが存在することがわかりました。私の個人的な好みは現在RAMLです。

Webサービスのしくみ

これは、特定のWebサービスで使用されているアーキテクチャとテクノロジに依存しているため、広範すぎる質問です。しかし、一般に、Webサービスは、クライアントからの要求を受け入れて応答を返すことができる、Web内の単なるアプリケーションです。Webに公開されているため、Webサービスであり、通常は24時間年中無休で利用できます。そのため、これはサービスです。もちろん、クライアントの問題を解決します（そうでなければ、なぜ誰かがWebサービスを使用するのでしょうか）。

これは、あなたが見つける最も簡単な説明です。

この記事では、夫から妻へのナラティブを取り上げ、夫がRESTについて純粋な素人の言葉で妻に説明します。必読！

how-i-explained-rest-to-my-wife（元のリンク）
how-i-explained-rest-to-my-wife（2013-07-19作業リンク）

SOAP-シンプルオブジェクトアクセスプロトコルはプロトコルです。

REST-表現状態の転送はアーキテクチャスタイルです！

SOAP 通常HTTPを介してメッセージを転送するために使用されるXMLプロトコル

RESTそしてSOAP、間違い なく相互に排他的ではありません。RESTfulアーキテクチャはHTTP、SOAPまたはその他の通信プロトコルを使用する場合があります。RESTWeb用に最適化されているため、最適HTTPな選択肢です。HTTPもですRoy Fieldingの論文で議論されて唯一のプロトコルでます。

RESTとSOAPは明らかに非常に異なりますが、この質問は、 RESTとHTTP、多くの場合、タンデムで使用されているが。これは主に、HTTPのシンプルさと、RESTful原則への非常に自然なマッピングによるものです。

基本的なREST原則

クライアントサーバー通信

クライアント/サーバーアーキテクチャでは、懸念事項が非常に明確に分離されています。RESTfulスタイルで構築されたすべてのアプリケーションは、原則としてクライアント/サーバーでなければなりません。

ステートレス

サーバーへの各クライアント要求では、その状態が完全に表現されている必要があります。サーバーは、サーバーコンテキストやサーバーセッション状態を使用せずに、クライアント要求を完全に理解できる必要があります。したがって、すべての状態をクライアントで保持する必要があります。ステートレス表現については、後で詳しく説明します。

キャッシュ可能

キャッシュ制約を使用すると、応答データをキャッシュ可能またはキャッシュ不可としてマークできます。キャッシュ可能とマークされたデータは、同じ後続の要求への応答として再利用できます。

均一なインターフェース

すべてのコンポーネントは、単一の統一されたインターフェースを介して相互作用する必要があります。すべてのコンポーネントの相互作用はこのインターフェースを介して行われるため、さまざまなサービスとの相互作用は非常に簡単です。インターフェースは同じです！これは、実装の変更を個別に行うことができることも意味します。このような変更は、基本的なコンポーネントの相互作用には影響しません。統一されたインターフェースは常に変更されないためです。1つの欠点は、インターフェイスに行き詰まっていることです。インターフェースを変更することで特定のサービスに最適化を提供できる場合、RESTがこれを禁止しているため、運が悪いです。ただし、明るい面としては、RESTはWeb用に最適化されているため、REST over HTTPの信じられないほどの人気があります。

上記の概念はRESTの特性を定義することを表し、RESTアーキテクチャをWebサービスなどの他のアーキテクチャと区別します。RESTサービスはWebサービスですが、Webサービスは必ずしもRESTサービスである必要はないことに注意してください。

RESTと上記の箇条書きの詳細については、REST デザインプリンシパルに関するこのブログ投稿を参照してください。

ブライアン・R・ボンディの答えが好きです。ウィキペディアがRESTの明確な説明を提供していることを追加したかっただけです。この記事では、SOAPと区別しています。

RESTは、可能な限り簡単に行われる状態情報の交換です。

SOAPは、XMLを使用するメッセージプロトコルです。

多くの人々がSOAPからRESTに移行した主な理由の1つは、SOAPベースのWebサービスに関連するWS- *（WS splatと呼ばれる）標準が非常に複雑であることです。仕様のリストについては、ウィキペディアを参照してください。これらの各仕様は非常に複雑です。

編集：何らかの理由でリンクが正しく表示されていません。REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

SOAP WebサービスとREST Webサービスの両方で、HTTPプロトコルと他のプロトコルも使用できます（SOAPはRESTの基盤となるプロトコルである可能性があります）。HTTPプロトコル関連のSOAPとRESTについてのみ説明します。これは、これらが最も頻繁に使用されるためです。

石鹸

SOAP（「単純な」オブジェクトアクセスプロトコル）は、プロトコル（およびW3C標準）です。SOAPメッセージを作成、送信、処理する方法を定義します。

• SOAPメッセージは、特定の構造を持つXMLドキュメントです。メッセージには、ヘッダーと本文セクションを含むエンベロープが含まれています。本文には、送信したい実際のデータがXML形式で含まれています。エンコーディングスタイルは2つありますが、通常はリテラルを選択します。つまり、アプリケーションまたはそのSOAPドライバーがデータのXMLシリアル化とシリアル化解除を行います。

• SOAPメッセージは、SOAP + XML MIMEサブタイプのHTTPメッセージとして送信されます。これらのHTTPメッセージはマルチパートにすることができるため、オプションでSOAPメッセージにファイルを添付できます。

• 明らかに、クライアントサーバーアーキテクチャを使用しているため、SOAPクライアントはSOAP websericeに要求を送信し、サービスはクライアントに応答を送信します。ほとんどのWebサービスは、WSDLファイルを使用してサービスを記述します。WSDLファイルには、送信するデータのXMLスキーマ（以下、XSD）と、WebサービスをHTTPプロトコルにバインドする方法を定義するWSDLバインディングが含まれています。2つのバインディングスタイルがあります。：RPCとドキュメント。RPCスタイルのバインディングにより、SOAP本体には、パラメーター（HTTP要求）または戻り値（HTTP応答）を持つ操作呼び出しの表現が含まれます。パラメータと戻り値は、XSDに対して検証されます。ドキュメントスタイルバインディングにより、SOAP本体には、XSDに対して検証されるXMLドキュメントが含まれます。ドキュメントバインディングスタイルはイベントベースのシステムに適していると思いますが、そのバインディングスタイルを使用したことはありません。RPCバインディングスタイルの方が普及しているため、ほとんどの人々はSOAPをXML / RPCの目的で分散アプリケーションで使用しています。通常、WebサービスはUDDIサーバーに問い合わせることによってお互いを見つけます。UDDIサーバーは、Webサービスの場所を格納するレジストリです。

SOAP RPC

したがって、私の意見では、最も普及しているSOAP WebサービスはRPCバインディングスタイルとリテラルエンコーディングスタイルを使用し、次のプロパティを持っています。

• URLを操作にマップします。
• SOAP + XML MIMEサブタイプのメッセージを送信します。
• サーバー側のセッションストアを持つことができ、それに関する制約はありません。
• SOAPクライアントドライバーは、サービスのWSDLファイルを使用して、RPC操作をメソッドに変換します。クライアント側アプリケーションは、これらのメソッドを呼び出すことによりSOAP Webサービスと通信します。そのため、ほとんどのSOAPクライアントはインターフェースの変更（メソッド名やパラメーターの変更の結果）によって壊れます。
• RDFを使用してインターフェースの変更によって中断せず、セマンティクスによって操作を見つけるSOAPクライアントを作成することは可能ですが、セマンティックWebサービスは非常にまれであり、必ずしも中断しないクライアントがあるとは限りません（おそらく）。

残り

REST（Representational State Transfer）は、Roy Fieldingの論文で説明されているアーキテクチャスタイルです。SOAPのようなプロトコルは関係ありません。制約のないnullアーキテクチャスタイルから始まり、RESTアーキテクチャの制約を1つずつ定義します。人々はすべてのREST制約を満たすWebサービスにRESTfulという用語を使用しますが、Roy Fieldingによれば、RESTレベルなどはありません。WebサービスがすべてのREST制約を満たしていない場合、それはREST Webサービスではありません。

REST制約

• クライアント-サーバーアーキテクチャ-この部分は誰もが知っていると思います。RESTクライアントはREST Webサービスと通信し、Webサービスは共通データ（以降のリソース状態）を維持し、クライアントに提供します。
• ステートレス-略語の「状態転送」部分：REST。クライアントはクライアントの状態（セッション/アプリケーションの状態）を維持するため、サービスにセッションストレージを含めることはできません。クライアントは、リソース状態の関連部分で応答するサービスへのすべての要求によって、クライアント状態の関連部分を転送します（それらによって維持されます）。そのため、リクエストにはコンテキストがありません。リクエストを処理するために必要な情報が常に含まれています。たとえば、HTTP基本認証では、ユーザー名とパスワードがクライアントによって保存され、リクエストごとに送信されるため、認証はリクエストごとに行われます。これは、ログインだけで認証が行われる通常のWebアプリケーションとは大きく異なります。インメモリ（javascript）、cookies、localStorageなどのクライアント側のデータストレージメカニズムを使用できます... 必要に応じてクライアントの状態の一部を永続化します。ステートレスの制約の理由は、サーバーが非常に高い負荷（何百万ものユーザー）であっても、すべてのクライアントのセッションを維持する必要がない場合でも、サーバーが適切にスケーリングするためです。
• キャッシュ-応答には、クライアントがキャッシュできるかどうかに関する情報が含まれている必要があります。これにより、スケーラビリティがさらに向上します。

• 均一なインターフェース

  • リソースの識別-RESTリソースはRDFリソースと同じです。フィールディングによると、何かに名前を付けることができる場合は、それをリソースにすることができます。たとえば、「現在の地元の天気」をリソースにする、「携帯電話」をリソースにする、または「特定のWebドキュメント」をリソースにすることができます。リソース。リソースを識別するには、リソースIDを使用できます：URLとURN（たとえば、本のISBN番号）。単一の識別子は特定のリソースにのみ属している必要がありますが、単一のリソースは多くの識別子を持つことができますhttps://example.com/api/v1/users?offset=50&count=25。URLにはいくつかあります仕様ますたとえば、パスが同じでクエリが異なるURLは同一ではない、またはパス部分にURLの階層データが含まれ、クエリ部分に非階層データが含まれている必要があります。これらは、RESTでURLを作成する方法の基本です。ところで URL構造はサービス開発者にとってのみ重要であり、実際のRESTクライアントはそれに関係しません。もう1つのよくある質問は、APIのバージョン管理です。これは簡単な問題です。Fieldingによると、リソースごとの唯一の定数はセマンティクスだからです。セマンティクスが変更された場合は、新しいバージョン番号を追加できます。従来の3番号バージョン管理を使用して、メジャー番号のみをURLに追加できます（https://example.com/api/v1/）。したがって、下位互換性のある変更では何も起こりません。下位互換性のない変更によって、新しいAPI rootで下位互換性のないセマンティクスが得られますhttps://example.com/api/v2/。https://example.com/api/v1/古いセマンティクスでを使用できるため、古いクライアントが壊れることはありません。
  • 表現によるリソースの操作-リソースの目的の表現（HTTPメソッドとリソース識別子と共に）をRESTサービスに送信することにより、リソース（リソースの状態）に関連するデータを操作できます。たとえば、結婚後にユーザーの名前を変更する場合は、目的のリソースの状態のJSON表現であるPATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}リクエスト、{name: "Mrs Smith"}つまり新しい名前を送信できます。これは逆に起こり、サービスはリソースの表現をクライアントに送信して、それらの状態を変更します。たとえば、新しい名前を読みたい場合は、GET https://example.com/api/v1/users/1?fields="name"取得リクエストを送信して、200 ok, {name: "Mrs Smith"}応答。そのため、この表現を使用してクライアントの状態を変更できます。たとえば、「Welcome to our page Mrs Smith！」を表示できます。メッセージ。リソースは、リソース識別子（URL）またはacceptリクエストで送信したヘッダーに応じて、多くの表現を持つことができます。たとえば、image/jpegリクエストがあれば、スミス夫人の画像（おそらくヌードではない）を送信できます。
  • 自己記述的メッセージ-メッセージには、メッセージの処理方法に関する情報が含まれている必要があります。たとえば、URIとHTTPメソッド、コンテンツタイプヘッダー、キャッシュヘッダー、データの意味を説明するRDFなど。標準のメソッドを使用することが重要です。HTTPメソッドの仕様を理解することが重要です。たとえば、GETはリクエストURLで識別される情報を取得することを意味し、DELETEはサーバーに特定のURLで識別されるリソースを削除するように要求することなどを意味します。HTTPステータスコードにも仕様があり、たとえば200は成功、201は意味です新しいリソースが作成された場合、404は、要求されたリソースがサーバー上で見つからなかったことなどを意味します。既存の標準を使用することは、RESTの重要な部分です。

  • アプリケーション状態のエンジンとしてのハイパーメディア（以下、HATEOAS）-ハイパーメディアは、ハイパーリンクを含むことができるメディアタイプです。Webでは、URLをアドレスバーに入力する代わりに、ハイパーメディア形式（通常はHTML）で記述されたリンクをたどって目標を達成します。RESTは同じ概念に従い、サービスによって送信される表現にはハイパーリンクを含めることができます。これらのハイパーリンクを使用して、サービスにリクエストを送信します。応答により、新しいクライアント状態などを構築するために使用できるデータ（およびおそらくさらに多くのリンク）を取得します。そのため、ハイパーメディアはアプリケーション状態（クライアント状態）のエンジンです。クライアントはハイパーリンクをどのように認識してたどるのでしょうか。人間にとっては非常に簡単です。リンクのタイトルを読み、入力フィールドに入力し、その後は1回クリックするだけです。JSON-LD with Hydra）またはハイパーメディア固有のソリューション（たとえば、IANAリンク関係およびHAL + JSONによるベンダー固有のMIMEタイプ）。多くの機械可読なXMLおよびJSONハイパーメディア形式がありますが、それらの短いリストにすぎません。

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • サイレン
    • コレクション+ JSON

    時々選ぶのが難しい...

• 階層化システム-クライアントとサービスの間で複数の層を使用できます。それらのどれも、それらのすぐ隣にある層についてだけではなく、これらすべての追加の層について知っているべきではありません。これらのレイヤーは、キャッシュとロードバランシングを適用することでスケーラビリティを向上させるか、セキュリティポリシーを適用できます。
• コードオンデマンド-JavaScriptのコードなど、クライアントの機能を拡張するコードをブラウザーに送り返すことができます。これはRESTの唯一のオプションの制約です。

REST Webサービス-SOAP RPC Webサービスの違い

したがって、REST WebサービスはSOAP Webサービスとは大きく異なります（RPCバインディングスタイルおよびリテラルエンコーディングスタイルを使用）

• それは（プロトコルの代わりに）統一されたインターフェースを定義します。
• URLをリソース（操作ではなく）にマップします。
• SOAP + XMLだけでなく、任意のMIMEタイプのメッセージを送信します。
• ステートレス通信であるため、サーバー側のセッションストレージを持つことはできません。（SOAPにはこれに関する制約はありません）
• ハイパーメディアを提供し、クライアントはそのハイパーメディアに含まれるリンクを使用してサービスを要求します。（SOAP RPCは、WSDLファイルに記述されている操作バインディングを使用します）
• セマンティクスの変更のみでURLが変更されても壊れません。（RDFセマンティクスを使用しないSOAP RPCクライアントは、WSDLファイルの変更によって壊れます。）
• ステートレスな動作のため、SOAP Webサービスよりもスケーラビリティが優れています。

等々...

SOAP RPC Webサービスは、すべてのREST制約を満たしていません。

• クライアントサーバーアーキテクチャ-常に
• ステートレス- 可能
• キャッシュ- 可能
• 統一されたインターフェース-決して
• 階層化システム- 決して
• オンデマンドのコード（オプション）-可能

さて、2つ目の質問から始めます。Webサービスとは何ですか。、明白な理由で。

WebServicesは基本的に、特定の機能またはデータを公開するロジック（漠然とメソッドと呼ぶ場合があります）です。実装するクライアント（技術的に言えば、消費することが言葉）は、メソッドが受け入れるパラメータと、メソッドが返すデータのタイプ（ある場合）を知る必要があるだけです。

次のリンクは、RESTとSOAPのすべてを非常に明快な方法で説明しています。

RESTとSOAP

何を選択するか（RESTまたはSOAP）も知りたい場合は、それを検討する理由がさらにあります！

SOAPとRESTはどちらも、異なるシステムが相互に通信する方法を指します。

RESTは、ブラウザーとWebサーバーとの通信に似た手法を使用してこれを行います。GETを使用してWebページを要求したり、フォームフィールドにPOSTしたりするなどです。

SOAPは同様の機能を提供しますが、XMLのブロックを送受信することですべてを行います。SOAPのもう1つの主要コンポーネントはWSDLです。これは、サポートされている関数とデータ要素を記述するXMLドキュメントです。WSDLを使用すると、サポートされている関数をプログラムで「検出」したり、プログラミングコードスタブを生成したりできます。

これは説明できるほど簡単だと思います。どうか、誰でも私を訂正するか、これに追加してください。

SOAPは、インターネット経由などの切断されたシステムが情報/データを交換するために使用するメッセージ形式です。これは、XMLメッセージのやり取りに関係しています。

WebサービスはSOAPメッセージを送信または受信します。使用する言語によって動作が異なります。

SOAPの問題は、HTTPスタックの背後にある理想と矛盾することです。ミドルウェアは、要求または応答の内容を理解せずにHTTP要求を処理できる必要がありますが、たとえば、通常のHTTPキャッシングサーバーは、SOAPコンテンツのどの部分のみがキャッシングに関係するのかを知らなければ、SOAP要求を処理できません。SOAPは、プロキシなどの独自の通信プロトコルのラッパーとしてHTTPを使用します。

RESTは、ネットワークアプリケーションを設計するためのアーキテクチャスタイルです。考え方は、CORBA、RPC、SOAPなどの複雑なメカニズムを使用してマシン間を接続するのではなく、単純なHTTPを使用してマシン間で呼び出しを行うというものです。

SOAP – "Simple Object Access Protocol"

SOAPは、インターネットを介したメッセージの転送、または少量の情報です。SOAPメッセージはXMLでフォーマットされ、通常はHTTPを制御して送信されます。

REST – "REpresentational State Transfer"

RESTは、ファンとサーバー間で情報を受信し、最終的に発生する初歩的な手続きであり、明確に定義された多くの標準がありません。情報は、JSON、XML、またはプレーンテキストとして送受信できます。SOAPと比較して軽量です。

SOAPベースのWebサービス要するに、SOAPベースのサービスモデルは、世界を、相互に制御することはできませんが、公開された契約を尊重することによって連携する必要のある同等のピアのエコシステムと見なします。これは乱雑な現実世界の有効なモデルであり、メタデータベースのコントラクトはSOAPサービスインターフェイスを形成します。

SOAPをXMLベースのリモートプロシージャコールに関連付けることはできますが、SOAPベースのWebサービステクノロジが柔軟で強力なメッセージングモデルに登場しました。

SOAPは、すべてのシステムが独立しており、他のシステムの内部および内部機能の知識を持つシステムはないと想定しています。そのようなシステムでできることのほとんどは、互いにメッセージを送信し、それらが実行されることを望んでいます。システムは、彼らが履行することを約束した契約を公開し、他のシステムはそれらとメッセージを交換するためにこれらの契約に依存しています。

システム間の契約はまとめてメタデータと呼ばれ、サービスの説明、サポートされるメッセージ交換パターン、およびサービスの品質を管理するポリシー（サービスは暗号化され、確実に配信される必要があるなど）で構成されます。サービスの説明は、詳細なものですシステムによって送受信されるデータ（メッセージ文書）の仕様。ドキュメントは、XMLスキーマ定義のようなXML記述言語を使用して記述されます。すべてのシステムが公開済みの契約を順守している限り、システムは相互運用でき、システムの内部への変更が他のシステムに影響を与えることはありません。すべてのシステムは、独自の内部実装をその契約との間で変換する責任があります

REST-表現の状態の転送。物理プロトコルはHTTPです。基本的に、RESTとは、URLで一意に識別可能なWeb上のすべての個別のリソースです。これらのリソースで実行できるすべての操作は、限定された一連の動詞（「CRUD」動詞）によって記述でき、HTTP動詞にマッピングされます。

RESTは、SOAPよりも「重い」ものではありません。

Webサービスの動作