SOAPとREST（違い）

Webサービス通信プロトコルとしてのSOAPとRESTの違いについての記事を読みましたが、SOAPに対するRESTの最大の利点は次のとおりだと思います。

1. RESTはより動的であり、UDDI（Universal Description、Discovery、およびIntegration）を作成および更新する必要はありません。

2. RESTはXML形式のみに制限されていません。RESTful Webサービスはプレーンテキスト/ JSON / XMLを送信できます。

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

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

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

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

少しプッシュして比較を確立しようとすると、SOAPとRESTの主な違いは、クライアントとサーバーの実装間の結合の度合いです。SOAPクライアントは、サーバーに密結合されたカスタムデスクトップアプリケーションのように機能します。クライアントとサーバーの間には厳格なコントラクトがあり、どちらかが何かを変更するとすべてが壊れると予想されます。変更後は常に更新する必要がありますが、契約が守られているかどうかを確認する方が簡単です。

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

RESTとは何か、およびRESTとSOAPとの違いを理解するには、これらが重要なポイントだと思います。

• RESTはプロトコルに依存しません。HTTPとは連動していません。Webサイトのftpリンクをたどることができるように、RESTアプリケーションは、標準化されたURIスキームがある任意のプロトコルを使用できます。

• RESTはCRUDからHTTPメソッドへのマッピングではありません。詳細については、この回答をお読みください。

• RESTは、使用しているパーツと同じくらい標準化されています。HTTPでのセキュリティと認証は標準化されているため、REST over HTTPを実行するときに使用します。

• RESTは、ハイパーメディアとHATEOASがなければRESTではありません。つまり、クライアントはエントリポイントURIしか認識しておらず、リソースはクライアントが従うべきリンクを返すことになっています。REST APIで実行できるすべてのことについてURIパターンを提供するこれらの豪華なドキュメントジェネレーターは、要点を完全に逃しています。彼らは標準に従うべきものを文書化しているだけでなく、それを行うと、APIの進化における特定の瞬間にクライアントを結合しているので、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が最適です。

RESTvs SOAPは正しい質問ではありません。

RESTとSOAPは異なり、プロトコルではありません。

RESTある建築様式とデザインネットワークベースのソフトウェア・アーキテクチャについては。

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

アブドゥルアジーズの質問@という事実照らすないRESTとHTTP、多くの場合、タンデムで使用されているが。これは主に、HTTPのシンプルさと、RESTful原則への非常に自然なマッピングによるものです。

基本的なREST原則

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

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

ステートレス

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

キャッシュ可能

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

均一なインターフェース

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

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

RESTと上記の箇条書きの詳細については、REST 設計原則に関するこのブログ投稿を参照してください。

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

SOAP（Simple Object Access Protocol）とREST（Representation State Transfer）はどちらも見事に美しいものです。だから私はそれらを比較していません。代わりに、RESTを使用することを選択したときとSOAPを使用するときに、画像を描こうとしています。

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

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

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

では、以下の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つは「汎用」トランスポートの使用ですが、RESTはHTTP / HTTPSを使用することです。SOAPはほとんどすべてのトランスポートを使用してリクエストを送信できますが、RESTはできません。したがって、SOAPを使用する利点がここにあります。

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

REST over HTTPについて話しているとき、HTTPに適用されるすべてのセキュリティ対策は継承されます。これはトランスポートレベルのセキュリティと呼ばれ、メッセージが回線内にある間だけメッセージを保護しますが、一度それを反対側に配信すると、わかりません。データが処理される実際のポイントに到達するまでに通過する必要があるステージの数。そしてもちろん、これらすべてのステージでHTTPとは異なるものを使用することもできます。だから休憩は完全に安全ではありませんよね？

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

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

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

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

以下は、「Java EE 6チュートリアル」です。RESTfulな設計は、次の条件を満たす場合に適していると述べています。見てください。

私の回答をお楽しみいただけましたら幸いです。

REST（REプレゼンテーションSテートT ransfer）
REプレゼンテーションSテートオブジェクトのであるT ransferred RESTは、我々は、オブジェクトを送信しない、つまりされ、我々は、オブジェクトの状態を送信します。RESTはアーキテクチャスタイルです。SOAPのような多くの標準を定義していません。RESTは、インターネット上で公開API（Facebook API、Google Maps API）を公開して、データのCRUD操作を処理するためのものです。RESTは、単一の一貫したインターフェースを介して名前付きリソースにアクセスすることに重点を置いています。

SOAP（S imple O bject A CCESS P rotocol）
SOAPは、独自のプロトコルをもたらし、サービスとしてアプリケーションロジック（ないデータ）の部分を露出させるに焦点を当てています。SOAPは操作を公開します。SOAPは名前付き操作へのアクセスに重点を置いており、各操作はいくつかのビジネスロジックを実装しています。SOAPは一般にWebサービスと呼ばれますが、これは誤称です。SOAPには、Webに関係するものはほとんどありません。RESTは、URIとHTTPに基づいた真のWebサービスを提供します。

なぜRESTなのか？

• RESTは標準のHTTPを使用しているため、これまでになく簡単です。
• RESTは実装が簡単で、必要な帯域幅とリソースが少なくて済みます。
• RESTは、SOAPがXMLのみを許可するように、多くの異なるデータ形式を許可します。
• RESTは、JSONをサポートしているため、ブラウザークライアントのサポートを改善できます。
• RESTはパフォーマンスとスケーラビリティが優れています。REST読み取りはキャッシュできますが、SOAPベースの読み取りはキャッシュできません。
• セキュリティが大きな懸念事項ではなく、リソースが限られている場合。または、他の開発者が簡単に使用できるAPIを作成したい場合は、RESTを使用する必要があります。
• ステートレスCRUD操作が必要な場合は、RESTを使用してください。
• RESTは、ソーシャルメディア、ウェブチャット、モバイルサービス、GoogleマップなどのパブリックAPIで一般的に使用されています。
• リクエストヘッダパラメータ「同意する」に応じて、同じリソースのためのRESTfulなサービスリターン様々なMediaTypes、application/xmlまたはapplication/jsonPOSTのためおよび/user/1234.jsonまたはGET /user/1234.xmlGETのために。
• RESTサービスは、エンドユーザーから直接ではなく、クライアント側のアプリケーションから呼び出されることを意図しています。
• ST RESTでは、から来ているSテイトT ransfer。サーバーに状態を保存する代わりに、状態を転送することで、RESTサービスをスケーラブルにします。

なぜSOAPなのか？

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

ソース1
ソース2

休息と石鹸の違い

石鹸

1. SOAPはプロトコルです。
2. SOAPはSimple Object Access Protocolの略です。
3. SOAPはプロトコルであるため、RESTを使用できません。
4. SOAPは、サービスインターフェースを使用してビジネスロジックを公開します。
5. SOAPは、厳密に準拠する標準を定義しています。
6. SOAPはRESTよりも多くの帯域幅とリソースを必要とします。
7. SOAPは独自のセキュリティを定義します。
8. SOAPはXMLデータ形式のみを許可します。
9. SOAPはRESTよりも優先されません。

残り

1. RESTはアーキテクチャスタイルです。
2. RESTは、Representational State Transferの略です。
3. RESTは概念であり、HTTP、SOAPなどの任意のプロトコルを使用できるため、SOAP Webサービスを使用できます。
4. RESTはURIを使用してビジネスロジックを公開します。
5. RESTはSOAPのような標準をあまり定義していません。
6. RESTは、SOAPよりも少ない帯域幅とリソースを必要とします。
7. RESTful Webサービスは、基盤となるトランスポートからセキュリティ対策を継承します。
8. RESTでは、プレーンテキスト、HTML、XML、JSONなどのさまざまなデータ形式を使用できます。
9. SOAPよりもRESTの方が望ましい。

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

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

SOAPはプロトコルであり、RESTはソフトウェアアーキテクチャパターンです。SOAPとRESTについて、インターネットには多くの誤解があります。

SOAPは、Webサービス対応アプリケーションがインターネット経由で相互に通信するために使用するXMLベースのメッセージ形式を定義します。そのためには、アプリケーションでメッセージコントラクト、データ型などの事前知識が必要です。

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

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

なぜならば、大まかに言うとWebサービスが使用されているため、Webページの代わりにHTTPプロトコルを使用してデータを転送する場合、公式にはそのアイデアの非常に特殊な形式です。定義によれば、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用語ではリソースと呼ばれます）を表す必要があります。HTTPプロトコル（既に使用しています）は動詞をサポートしているため、これらの動詞を使用して、Thingで実行するアクションを指定します。

したがって、RESTアプローチでは、顧客番号12はURLで見つかりますmyapp/customers/12。顧客データを表示するには、GETリクエストでURLをヒットします。それを削除するには、DELETE動詞を使用した同じ URL。これを更新するには、POST動詞を含む同じ URLと、リクエストの本文に新しいコンテンツを含めます。

真にRESTfulと見なされるためにサービスが満たさなければならない要件の詳細については、Richardson成熟度モデルを参照してください。この記事では例を示し、さらに重要なことに、（いわゆる）SOAPサービスがレベル​​0のRESTサービスである理由を説明します（ただし、レベル0はこのモデルへのコンプライアンスが低いことを意味し、攻撃的ではなく、依然として有用です）多くの場合）。

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

追加：

++ RESTに近づくときによくある間違いは、RESTを「URLを使用するWebサービス」と考えることです。RESTをSOAPのような別のリモートプロシージャコール（RPC）メカニズムと考えますが、プレーンなHTTP URLを介して呼び出され、SOAPの大きな負荷はかかりません。 XML名前空間。

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

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

この記事では、特定のSOAP機能に煩わされることなく、概念の違いについて説明します。