SOAP vs REST （違う）

Question

Webサービスの通信プロトコルとしてのSOAPとRESTの違いについての記事を読みましたが、RESTよりもSOAPは以下のとおりです。

RESTはより動的であり、UDDI（Universal Description、Discovery、およびIntegration）を作成および更新する必要はありません。
RESTはXMLフォーマットのみに制限されていません。 RESTful Webサービスはプレーンテキスト/ JSON/XMLを送信できます。

しかしSOAPはより標準化されています（例：セキュリティ）。

それで、私はこれらの点で正しいですか？

Pedro Werneck · Accepted Answer

残念ながら、RESTに関しては多くの誤情報や誤解があります。あなたの質問と @cmd による回答）だけでなく、Stack Overflowの主題に関する質問と回答のほとんどを反映しています。

SOAPとRESTを直接比較することはできません。最初のプロトコルはプロトコルであり（または少なくともそうしようとしている）、2番目のアーキテクチャはアーキテクチャスタイルであるためです。人々がSOAPではないHTTP APIをREST呼び出す傾向があるので、これはおそらくそれをめぐる混乱の原因の1つです。

少し物事を進めて比較を確立しようとすると、SOAPとRESTの主な違いは、クライアントとサーバーの実装間のカップリングの程度です。 SOAPクライアントはカスタムデスクトップアプリケーションのように機能し、サーバーと緊密に連携しています。クライアントとサーバーの間には厳格な契約があり、どちらかが何かを変更すると、すべてが壊れることが予想されます。あなたはどんな変化の後でも絶えず更新する必要があります、しかし、契約が守られているかどうか確かめることはより簡単です。

RESTクライアントはブラウザに似ています。プロトコルと標準化されたメソッドの使い方を知っているのは一般的なクライアントであり、アプリケーションはその中に収まる必要があります。追加のメソッドを作成してプロトコル標準に違反することはなく、標準のメソッドを利用してメディアタイプにアクションを作成します。正しく行われれば、結合は少なくなり、変更はより優雅に対処されることができます。エントリポイントとメディアタイプを除いて、クライアントはAPIの知識がなくてもRESTサービスに入るはずです。 SOAPでは、クライアントは使用することすべてについての事前の知識が必要です。そうしないと対話を開始することすらありません。さらに、RESTクライアントは、サーバー自体が提供するコードオンデマンドによって拡張することができます。その典型的な例は、クライアントサイドの他のサービスとの対話を促進するために使用されるJavaScriptコードです。

私はこれらがRESTが何であるか、そしてそれがSOAPとどう違うのかを理解するための重要なポイントであると思います：

RESTはプロトコルに依存しません。 HTTPとは連携していません。あなたがウェブサイトのftpリンクをたどることができるのとほとんど同じように、RESTアプリケーションは標準化されたURIスキームがあるどんなプロトコルも使うことができます。
RESTはCRUDからHTTPメソッドへのマッピングではありません。その詳細な説明は this answerを読んでください。
RESTは、使用している部分と同じくらい標準化されています。 HTTPのセキュリティと認証は標準化されているので、HTTPを介してRESTを実行するときにそれを使用します。
RESTは hypermedia と HATEOAS なしではRESTではありません。つまり、クライアントはエントリポイントURIしか知っておらず、リソースはクライアントがたどるべきリンクを返すはずです。 REST APIでできることすべてのためのURIパターンを提供するジェネレータは、その点を完全に見逃していますが、標準に従っているはずのものを文書化しているだけではありません。 APIの進化における1つの特定の瞬間、およびAPIに対するいかなる変更も文書化され適用されなければならず、さもなければそれは壊れるでしょう。
RESTはWeb自体のアーキテクチャスタイルです。 Stack Overflowに入ると、ユーザー、質問、回答が何であるか、メディアの種類がわかり、Webサイトからそれらへのリンクが提供されます。 REST APIも同じことをする必要があります。質問と回答へのリンクを含むホームページを用意するのではなく、RESTの実行方法に合わせてWebを設計した場合は、質問を表示するには次のように説明する静的なドキュメントが必要です。 URI stackoverflow.com/questions/<id>を取り、idをQuestion.idに置き換えてブラウザに貼り付けます。それはナンセンスですが、それは多くの人々がRESTであると思うものです。

この最後の点は十分強調することはできません。クライアントがドキュメント内のテンプレートからURIを作成していて、リソース表現内にリンクを取得していない場合、それはRESTではありません。 RESTの作者であるRoy Fieldingは、このブログ投稿で次のように述べています。 REST APIはハイパーテキスト駆動型でなければなりません。

上記を念頭に置いて、RESTはXMLに限定されないかもしれませんが、他の形式で正しく行うには、リンク用の形式を設計および標準化する必要があることがわかります。ハイパーリンクはXMLでは標準的ですが、JSONでは標準的ではありません。 HAL のような、JSONのためのドラフト標準があります。

最後に、RESTは万人向けではありません。その証明は、ほとんどの人が誤ってRESTと呼んだHTTP APIを使用して問題を非常にうまく解決し、それ以上のことを試みないことです。 RESTは、特に最初のうちは実行するのが難しい場合がありますが、時間が経つにつれてサーバー側の進化が容易になり、クライアントの変更に対する回復力が高まります。迅速かつ簡単に何かをする必要がある場合は、RESTを正しくすることを気にしないでください。それはおそらくあなたが探しているものではありません。何年も何十年もオンラインでいなければならないものが必要な場合は、RESTを選択してください。

cmd · Answer

REST vs SOAPは not 正しい質問です。

RESTは、SOAPとは異なり、 not プロトコルです。

RESTはネットワークベースのソフトウェアアーキテクチャのためのアーキテクチャスタイルとデザインです。

RESTの概念はリソースと呼ばれます。リソースの表現はステートレスでなければなりません。それはいくつかのメディアタイプによって表されます。メディアタイプの例には、XML、JSON、およびRDFがあります。リソースはコンポーネントによって操作されます。コンポーネントは標準の統一インタフェースを介してリソースを要求し操作します。ＨＴＴＰの場合、このインターフェースは標準のＨＴＴＰｏｐｓからなる。 GET、PUT、POST、DELETE。

@ Abdulazizの質問は、RESTとHTTPがしばしば一緒に使われるという事実を明らかにしています。これは主にHTTPの単純さとRESTfulな原則への非常に自然なマッピングによるものです。

基本REST原則

クライアントとサーバー間の通信

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

ステートレス

サーバーへの各クライアント要求は、その状態が完全に表現されていることを必要とします。サーバーは、サーバーコンテキストまたはサーバーセッション状態を使用せずに、クライアント要求を完全に理解できなければなりません。その結果、すべての状態はクライアント上で維持される必要があります。

キャッシュ可能

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

統一インターフェース

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

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

_ rest _ および上記の箇条書きの詳細については、このブログを参照してください。 post on RESTデザイン原則。

編集： コメントに基づいてコンテンツを更新する

Bacteria · Answer

SOAP（Simple Object Access Protocol）およびREST（Representation State Transfer）はどちらも美しい方法です。だから私はそれらを比較していません。代わりに、RESTを使用することを好み、SOAPを使用する場合に、画像を表示しようとしています。

ペイロードとは何ですか？

データがインターネット経由で送信される場合、送信される各ユニットには、ヘッダー情報と送信される実際のデータの両方が含まれます。ヘッダーはパケットのソースと宛先を識別します。実際のデータはペイロードと呼ばれます。一般に、ペイロードは、アプリケーションに代わって運ばれるデータと宛先システムによって受信されるデータです。

ここで、たとえば、Telegramを送信する必要がありますが、電報のコストがいくつかの単語に依存することは誰もが知っています。

だから、これらの2つのメッセージのうち、どちらを送信する方が安価ですか？

<name>Arin</name>

または

"name": "Arin"

同じメッセージを表す2番目のメッセージはどちらもコストに関して安くなりますが、2番目の答えになることはわかっています。

だから、ネットワーク上でJSON形式でデータを送信するデータは、ペイロードに関してXML形式で送信するよりも安いと言いたいと思います。

SOAPに対するRESTの最初の利点は次のとおりです。 SOAPはXMLのみをサポートしますが、RESTはテキスト、JSON、XMLなどの異なる形式をサポートします。Jsonを使用すれば、ペイロードに関して間違いなく適切な場所になります。。

現在、SOAPは唯一のXMLをサポートしていますが、利点もあります。

本当に！方法

SOAPは、メッセージに含まれるものとその処理方法を定義する3つの方法でEnvelopeにXMLを使用します。

データ型の一連のエンコード規則、および最後に収集されたプロシージャ呼び出しと応答のレイアウト。

このエンベロープはトランスポート（HTTP/HTTPS）を介して送信され、RPC（リモートプロシージャコール）が実行され、XML形式のドキュメントの情報とともにエンベロープが返されます。

重要な点は、SOAPの利点の1つは「generic」transportを使用することですが、RESTはHTTP/HTTPS。 SOAPはほとんどすべてのトランスポートを使用して要求を送信できますが、RESTは送信できません。ここで、SOAPを使用する利点を得ました。

上記の段落で既に述べたように「RESTはHTTP/HTTPSを使用します」なので、これらの単語についてもう少し詳しく説明します。

HTTPを介してRESTについて話している場合、HTTPに適用されるすべてのセキュリティ対策が継承され、これはtransport level securityと呼ばれ、それはワイヤ内にありますが、反対側でそれを配信すると、データが処理される実際のポイントに到達するまでにいくつのステージを通過する必要があるかがわかりません。そしてもちろん、これらのすべての段階はHTTPとは異なるものを使用できます。だから、Restは完全に安全ではありませんよね？

ただし、SOAPはRESTと同様にSSLをサポートしますまた、エンタープライズを追加するWS-Securityもサポートしますセキュリティ機能。 WS-Securityは、メッセージの作成から消費までの保護を提供します。そのため、WS-Securityを使用して防ぐことができる抜け穴が何であれ、トランスポートレベルのセキュリティのために。

それとは別に、RESTはHTTPプロトコルによって制限されているため、トランザクションサポートはACID準拠ではなく、分散した多国籍リソース間で2フェーズコミットを提供できません。

ただし、SOAPは、短期間トランザクションのACIDベースのトランザクション管理と、長時間実行トランザクションの補償ベースのトランザクション管理の両方を包括的にサポートしています。また、分散リソース全体での2フェーズコミットもサポートしています。

私は結論を導き出していませんが、SOAPベースのWebサービスを優先しますが、セキュリティ、トランザクションなどが主な関心事です。

ここに、「Java EE 6チュートリアル」があります以下の条件が満たされたときにRESTfulな設計が適切かもしれません。ご覧ください。

私の答えを読んで楽しんでくれたことを願っています。

Premraj · Answer

REST（REpresentationalStateTransfer）
REpresentationalState ofオブジェクトはTransferredはRESTです。つまり、オブジェクトを送信せず、オブジェクトの状態を送信します。 RESTは建築スタイルです。 SOAPのような多くの標準を定義していません。 RESTは、パブリックAPI（Facebook API、Google Maps APIなど）をインターネット経由で公開して、データのCRUD操作を処理するためのものです。 RESTは、単一の一貫したインターフェースを介して名前付きリソースにアクセスすることに焦点を当てています。

SOAP（SimpleObjectAccessProtocol）
SOAPは独自のプロトコルを提供し、アプリケーションロジック（データではない）をサービスとして公開することに焦点を当てています。 SOAPは操作を公開します。 SOAPは名前付き操作へのアクセスに焦点を当てており、各操作はいくつかのビジネスロジックを実装します。 SOAPは一般的にwebサービスと呼ばれますが、これは間違っています。 SOAPは、Webと関係があるとしても非常にわずかです。 RESTは、URIおよびHTTPに基づいてtrueWebサービスを提供します。

なぜRESTなのか？

RESTは標準のHTTPを使用するため、ほぼ単純な方法です。
RESTは実装が簡単で、必要な帯域幅とリソースが少なくて済みます。
RESTは、SOAPがXMLのみを許可するさまざまなデータ形式を許可します。
RESTでは、JSONがサポートされているため、ブラウザークライアントのサポートが向上しています。
RESTの方がパフォーマンスとスケーラビリティが優れています。 REST読み取りはキャッシュできます。SOAPベースの読み取りはキャッシュできません。
セキュリティが大きな問題ではなく、リソースが限られている場合。または、他の開発者が簡単に公開して使用できるAPIを作成する場合は、RESTを使用する必要があります。
ステートレスCRUD操作が必要な場合は、RESTを使用します。
RESTは、ソーシャルメディア、ウェブチャット、モバイルサービス、GoogleマップなどのパブリックAPIで一般的に使用されています。
RESTfulサービスは、POSTのapplication/xmlまたはapplication/jsonおよびGETの/user/1234.jsonまたはGET /user/1234.xmlの要求ヘッダーパラメーター「Accept」に応じて、同じリソースのさまざまなMediaTypeを返します。
RESTサービスは、エンドユーザーではなく、クライアント側アプリケーションによって呼び出されることを意図しています。
STin REST from fromStateT転送。サーバーに状態を保存させる代わりに状態を転送すると、RESTサービスがスケーラブルになります。

なぜSOAP？

SOAPの実装はそれほど簡単ではなく、より多くの帯域幅とリソースが必要です。
SOAPメッセージ要求は、RESTと比べて処理が遅く、Webキャッシングメカニズムを使用しません。
WS-Security：SOAPは（RESTと同様に）SSLをサポートしますが、エンタープライズセキュリティ機能を追加するWS-Securityもサポートします。
WS-AtomicTransaction：サービスを介したACIDトランザクションが必要です。SOAPが必要になります。
WS-ReliableMessaging：アプリケーションが非同期処理と信頼性とセキュリティの保証されたレベルを必要とする場合。 Restには標準のメッセージングシステムがないため、クライアントが再試行することで通信障害に対処することを期待しています。
セキュリティが大きな懸念事項であり、リソースが制限されていない場合は、SOAP Webサービスを使用する必要があります。支払いゲートウェイ、金融、および通信関連の作業用のWebサービスを作成している場合、ここでは高いセキュリティが必要であるため、SOAPを使用する必要があります。

source1
source2

Rex · Answer

休息と石鹸の違い

_石鹸_

SOAPはプロトコルです。
SOAPはSimple Object Access Protocolの略です。
プロトコルであるため、SOAPはRESTを使用できません。
SOAPは、サービスロジックを使用してビジネスロジックを公開します。
SOAPは標準に厳密に従うように定義しています。
SOAPはRESTよりも多くの帯域幅とリソースを必要とします。
SOAPは独自のセキュリティを定義しています。
SOAPはXMLデータフォーマットのみを許可します。
SOAPはRESTよりも好まれません。

_ rest _

RESTは建築スタイルです。
RESTはRepresentational State Transferの略です。
RESTは概念であり、HTTP、SOAPなどの任意のプロトコルを使用できるため、SOAP Webサービスを使用できます。
RESTはURIを使用してビジネスロジックを公開します。
RESTは、SOAPのようにあまりにも多くの標準を定義していません。
RESTはSOAPよりも少ない帯域幅とリソースしか必要としません。
RESTful Webサービスは、基礎となるトランスポートからセキュリティ対策を継承します。
RESTは、プレーンテキスト、HTML、XML、JSONなどのさまざまなデータフォーマットを許可します。
SOAPよりRESTのほうが優先されます。

詳細はこちらをご覧ください。

marvelTracker · Answer

私見あなたはSOAPとRESTを比較することはできません。

_ soap _ はプロトコル、 _ rest _ はソフトウェアアーキテクチャパターンです。インターネットには SOAP vs _ REST の誤解がたくさんあります。

_ soap _ は、Webサービス対応アプリケーションがインターネットを介して互いに通信するために使用するXMLベースのメッセージフォーマットを定義します。そのためには、アプリケーションはメッセージコントラクト、データ型などに関する事前の知識が必要です。

_ rest _ はURLからサーバーの状態を（リソースとして）表します。ステートレスであり、クライアントはハイパーメディアの理解以上にサーバーと対話するための事前知識を持ってはいけません。

Jose Manuel Gomez Alvarez · Answer

多くの回答ですでに取り上げられている他の多くのものの中で、SOAPは契約、WSDL、サポートされる操作を定義すること、複合型などを定義できることを強調します。SOAPしかし、RESTはリソース指向です。個人的には、内部のエンタープライズアプリケーション間の複雑なインタフェースにはSOAPを、外部とのパブリックでシンプルでステートレスなインタフェースにはRESTを選択します。

blue_note · Answer

まず第一に、公式には、正しい質問はweb services + WSDL + SOAP対RESTです。

なぜなら、web service、はゆるい意味で使われていますが、HTTPプロトコルを使ってWebページの代わりにdataを転送する場合、公式それは非常に特殊な形式です。その考えの。定義によると、RESTは「Webサービス」ではありません。

しかし実際には、誰もがそれを無視するので、それも無視しましょう

すでに技術的な答えがあるので、私は直感を提供しようとします。

他のプログラミング言語で実装されたリモートコンピュータの関数を呼び出したいとしましょう（これはしばしばリモートプロシージャコール/ RPCと呼ばれます）。その機能は、それを書いた人によって提供された特定のURLで見つけることができると仮定します。あなたは（どういうわけか）それにメッセージを送って、そして何らかの応答を得る必要があります。そのため、考慮すべき主な質問が2つあります。

送信するメッセージの形式は何ですか
メッセージをどのようにやり取りするのか

最初の質問では、公式の定義は _ wsdl _ です。これは、パラメータとは何か、それらのタイプとは何か、名前、デフォルト値、呼び出される関数の名前などを詳細かつ厳密な形式で記述したXMLファイルです。 WSDLの例ここに示すのはファイルは人間が読むことができます（しかし容易ではありません）。

2番目の質問については、さまざまな答えがあります。ただし、実際に使用されるのは _ soap _ だけです。その主なアイデアは、以前のXML（実際のメッセージ）をさらに別のXML（エンコード情報やその他の役立つものを含む）にラップし、それをHTTPで送信することです。 HTTPのPOSTメソッドは常に本文があるなので、メッセージの送信に使用されます。

このアプローチ全体の主な考え方は、URLを関数にマップする、つまり アクション にすることです。したがって、あるサーバーに顧客のリストがあり、それを表示/更新/削除したい場合は、3つのURLが必要です。

myapp/read-customerとメッセージの本文に、読む顧客のIDを渡します。
myapp/update-customerと本文に、顧客のIDと新しいデータを渡します。
本体のmyapp/delete-customerとid

RESTアプローチでは、状況が異なります。 URLはアクションを表すべきではありませんが、もの（REST用語ではresourceと呼ばれます）。 HTTPプロトコル（現在使用しているプロトコル）は動詞をサポートしているので、どのような動作を指定するためにそれらの動詞を使用してください _ものに対して実行する_。

したがって、RESTアプローチでは、顧客番号12がURL myapp/customers/12に見つかります。顧客データを表示するには、GETリクエストでURLにアクセスします。削除するには、同じ URLにDELETE動詞を付けます。それを更新するには、 再度、同じ URLとPOST動詞を付けて、リクエスト本文に新しいコンテンツを追加します。

真にRESTfulであると見なされるためにサービスが満たさなければならない要件についての詳細は、 Richardson成熟度モデルを参照してください。この記事では例を挙げて、さらに重要なことに、（いわゆる）SOAPサービスがなぜレベル0 RESTサービスであるのかを説明します（ただし、レベル0は、標準への準拠が低いことを意味しますこのモデルは、それは不快ではありません、そしてそれはまだ多くの場合に便利です）。

Quan Nguyen · Answer

のための追加：

++ RESTに近づくときによくある間違いは、それを「URL付きのWebサービス」と考えることです - RESTを別のリモートプロシージャコール（RPC）メカニズムと考えることSOAP。ただし、単純なHTTP URLを介して呼び出され、SOAPの高額なXML名前空間は使用されません。

++反対に、RESTはRPCとはほとんど関係ありません。 RPCはサービス指向でアクションや動詞に焦点を当てていますが、RESTはリソース指向で、アプリケーションを構成するものや名詞を強調しています。

Phil Sturgeon · Answer

これらの答えの多くは、完全にRESTの基本であるハイパーメディアコントロール（HATEOAS）について言及することを完全に忘れていました。他の何人かはそれについて触れました、しかしそれをあまりよく説明しませんでした。

この記事は特定のSOAP機能に関する雑草に陥ることなく、概念間の違いを説明するべきです。