Webサービスの場合はSOAPまたはRESTですか？
RESTはWebサービスを行うためのより良いアプローチですか、それともSOAPですか？それとも、問題ごとに異なるツールですか？それとも微妙な問題ですか？つまり、特定のアリーナでは他のアリーナよりもわずかに優れていますか？
特に、これらの概念と、PHPユニバースおよび最新のハイエンドWebアプリケーションとの関係に関する情報をいただければ幸いです。
Hewlett-Packardで働いていたときに、開発中の元の仕様から、コード生成やWSDL生成を含む最初のSOAPサーバーの1つを構築しました。 SOAPを使用することはお勧めしません。
頭字語「SOAP」は嘘です。シンプルではなく、オブジェクト指向ではなく、アクセスルールを定義しません。これは、ほぼ間違いなくプロトコルです。これはドン・ボックスの史上最悪のスペックであり、彼は「COM」を実行した人物であるため、それは非常に偉業です。
SOAPには、トランスポートにはRESTで、データ表現にはJSON、XML、さらにはプレーンテキストでは実行できない便利なものはありません。トランスポートのセキュリティのために、httpsを使用できます。認証の場合、基本認証。セッションには、Cookieがあります。 RESTバージョンはよりシンプルで明確になり、実行速度が速くなり、使用する帯域幅が少なくなります。
XML-RPCは要求、応答、およびエラープロトコルを明確に定義しており、ほとんどの言語に適したライブラリがあります。ただし、XMLは多くのタスクに必要な量よりも重いです。
RESTはアーキテクチャであり、SOAPはプロトコルです。
それが最初の問題です。
SOAPエンベロープをRESTアプリケーションで送信できます。
SOAP自体は実際には非常に基本的でシンプルであり、SOAPを非常に複雑にするのはWSS- *標準です。
消費者が他のアプリケーションや他のサーバーである場合、今日のSOAPプロトコルのサポートが多くあり、データの移動の基本は基本的に現代のIDEでのマウスクリックです。
消費者がRIAまたはAjaxクライアントである可能性が高い場合は、おそらくSOAPよりもシンプルで、クライアントにネイティブなもの（特にJSON）が必要です。
HTTP経由で送信されるJSONパケットは、必ずしもRESTアーキテクチャではなく、単にURLへのメッセージです。すべて完全に機能しますが、RESTイディオムには重要な要素があります。ただし、この2つを混同するのは簡単です。しかし、HTTPリクエストを話しているからといって、必ずしもRESTアーキテクチャを持っているとは限りません。 HTTPをまったく使用しないRESTアプリケーションを使用できます（これはまれです）。
そのため、SOAPに「快適」なサーバーとコンシューマーがあれば、SOAPとWSSスタックが役立ちます。アドホックな操作をより多く行い、Webブラウザーとのインターフェイスを改善したい場合は、HTTPを介したより軽いプロトコルも適切に機能します。
RESTは、SOAPとは根本的に異なるパラダイムです。 RESTの良い読み物はここにあります： RESTを妻にどのように説明したか 。
読む時間がない場合は、ここに短いバージョンがあります。RESTは、「名詞」に焦点を合わせ、それらの名詞に適用できる「動詞」の数を制限することによる、ちょっとしたパラダイムシフトです。許可される動詞は、「get」、「put」、「post」、および「delete」のみです。これは、多くの異なる動詞を多くの異なる名詞（つまり、多くの異なる機能）に適用できるSOAPとは異なります。
RESTの場合、4つの動詞は対応するHTTP要求にマップされますが、名詞はURLによって識別されます。これにより、サーバー上の状態とクライアント上の状態が不明な場合が多いSOAPに比べて、状態管理がはるかに透過的になります。
実際には、これの大部分は落ちますが、RESTは通常、 JSON で結果を返す単純なHTTPリクエストを指しますが、SOAPは通信するより複雑なAPIですXMLを渡します。どちらにも長所と短所がありますが、私の経験では、SOAPから得られるすべての機能が必要になることはめったにないため、RESTが通常より良い選択であることがわかりました。
2012年の質問の簡単な説明：
RESTが本当にうまく機能する領域は次のとおりです。
制限された帯域幅とリソース。戻り構造は実際には任意の形式（開発者定義）であることを忘れないでください。さらに、RESTアプローチは標準のGET、PUT、POST、およびDELETE動詞を使用するため、任意のブラウザーを使用できます。繰り返しになりますが、RESTは、現代のほとんどのブラウザが現在サポートしているXMLHttpRequestオブジェクトを使用することもできます。これにより、AJAXの特別なボーナスが追加されます。
完全にステートレスな操作。操作を継続する必要がある場合、RESTは最善のアプローチではなく、SOAPはより適切な場合があります。ただし、ステートレスCRUD（作成、読み取り、更新、および削除）操作が必要な場合、RESTはそれです。
キャッシング状況 RESTアプローチの完全なステートレス操作のために情報をキャッシュできる場合、これは完璧です。上記3つの多くのソリューションをカバーしています。
では、なぜSOAPを検討するのでしょうか？繰り返しますが、SOAPはかなり成熟しており、明確に定義されており、完全な仕様が付属しています。 RESTアプローチはまさにそれであり、開発のために広く開かれているので、次のものがある場合、SOAPは素晴らしいソリューションです。
非同期処理と呼び出し。アプリケーションで保証されたレベルの信頼性とセキュリティが必要な場合、SOAP 1.2は、このタイプの操作を保証する追加の標準を提供します。 WSRM-WS-Reliable Messagingのようなもの。
正式な契約両サイド（プロバイダーとコンシューマー）が交換フォーマットに同意する必要がある場合、SOAP 1.2はこのタイプの相互作用の厳格な仕様を提供します。
ステートフル操作。アプリケーションがコンテキスト情報と会話状態管理を必要とする場合、SOAP 1.2には、それらをサポートするためのWS *構造の追加仕様（セキュリティ、トランザクション、調整など）があります。それに比べて、RESTアプローチにより、開発者はこのカスタム配管を構築できます。
SOAPは現在、より優れたツールの利点を備えており、サービス層だけでなく、任意のWSDLからクライアントを生成するための多くの定型コードを生成します。
RESTはよりシンプルで、結果として維持しやすく、Webアーキテクチャの中心にあり、プロトコルの可視性が向上し、WWW自体のサイズに合わせて拡張できることが実証されています。いくつかのフレームワークは、REST on RailsのようなRubyサービスの構築を支援し、またいくつかはADO.NET Data Servicesのようなクライアントの作成を支援します。しかし、ほとんどの場合、ツールのサポートが不足しています。
WSDLはツールによって非常に簡単に消費されるため、SOAPはツールの観点から便利です。そのため、お気に入りの言語でWebサービスクライアントを生成できます。
RESTは、AJAXのWebページでうまく機能します。リクエストをシンプルに保つと、JavaScriptから直接サービス呼び出しを行うことができ、非常に便利です。応答XMLに名前空間が含まれないようにしてください。ブラウザーがそれらに詰まっているのを見ました。したがって、xsi：typeはおそらく機能しません。過度に複雑なXMLスキーマは機能しません。
RESTのパフォーマンスも向上する傾向があります。 REST応答を生成するコードのCPU要件は、SOAPフレームワークが示すものよりも低くなる傾向があります。また、サーバー側にXML生成アヒルが並んでいる場合は、XMLをクライアントに効果的にストリーミングできます。したがって、データベースカーソルの行を読んでいると想像してください。行を読み取るときに、それをXML要素としてフォーマットし、それをサービスコンシューマに直接書き込みます。この方法では、XML出力の書き込みを開始する前にメモリ内のすべてのデータベース行を収集する必要はありません-同時に読み取りと書き込みを行います。新しいテンプレートエンジンまたはXSLTを調べて、RESTでストリーミングを機能させます。
一方、SOAPは、ツールによって生成されたサービスによって大きなblobとして生成され、その後にのみ書き込まれる傾向があります。これは絶対的な真実ではありません。添付ファイルを使用するなど、SOAPからストリーミング特性を取得する方法があります。
私の意思決定プロセスは次のとおりです：消費者が簡単にサービスを提供したい場合、私が書くメッセージは中小規模（10MB以下）になり、余分なCPUを燃やすことは気にしませんサーバーでのサイクル、SOAPを使用します。 WebブラウザーでAJAXにサービスを提供する必要がある場合、またはストリーミングする必要がある場合、または応答が巨大な場合は、RESTに進みます。
最後に、適切なツールを使用している場合は、WS-SecurityやステートフルWebサービスの取得など、SOAPを中心に構築できる多くの優れた標準をプラグインできます。そのようなものは本当に違いを生み、毛深い要件を満たすのに役立ちます。
これは古い質問ですが、答えを投稿する必要があります。誰かが役に立つと思うかもしれません。 SOAPでRESTを推奨している人の数は信じられません。私は、これらの人々が開発者ではないか、合理的なサイズのRESTサービスを実際に実装したことはないと想定できます。 RESTサービスの実装は、SOAPサービスの実装よりも時間がかかります。そして、最終的にはさらに厄介になります。私がSOAP 99％の時間を選択する理由は次のとおりです。
1）RESTサービスの実装は、SOAPサービスの実装よりも無限に時間がかかります。すべての最新の言語/フレームワーク/プラットフォーム用のツールがあり、WSDLを読み取り、プロキシクラスとクライアントを出力します。 RESTサービスの実装は手作業で行われ、ドキュメントを読むことで取得します。さらに、これらの2つのサービスを実装する際に、実際のスキーマまたは参照ドキュメントがないため、パイプを介して戻るものについて「推測」する必要があります。
2）とにかくXMLを返すRESTサービスを書くのはなぜですか？唯一の違いは、RESTを使用すると、各要素/属性が表す型がわからないということです。自分で実装して、ある日、フィールドで文字列が出会わないことを望みます。考えは常にintでした。 SOAPはWSDLを使用してデータ構造を定義するため、これは簡単です。
3）SOAPでは、SOAPエンベロープの「オーバーヘッド」があるという苦情を聞きました。今日、私たちは本当に少数のバイトを心配する必要がありますか？
4）RESTを使用すると、ブラウザにURLをポップしてデータを表示できるという議論を聞いたことがあります。もちろん、RESTサービスがシンプル認証を使用しているか、認証を使用していない場合。たとえば、NetflixサービスはOAuthを使用します。これには、リクエストを送信する前に、署名とエンコードが必要です。
5）リソースごとに「読み取り可能な」URLが必要なのはなぜですか？ツールを使用してサービスを実装している場合、実際のURLを本当に気にしますか？
続ける必要がありますか？
私が書いたアプリケーションのほとんどは、サーバー側のC＃またはJava、またはWinFormsまたはWPFのデスクトップアプリケーションです。これらのアプリケーションは、RESTが提供できるよりも豊富なサービスAPIを必要とする傾向があります。さらに、Webサービスクライアントを作成するのに数分しか費やしたくありません。 WSDL処理クライアント生成ツールを使用すると、クライアントを実装し、ビジネス価値の追加に進むことができます。
さて、javascript ajax呼び出しのためにWebサービスを明示的に記述している場合、おそらくRESTにあります。クライアントテクノロジーを知り、JSONを活用するためだけです。私の意見では、javascriptから使用されるWebサービスAPIはおそらくそれほど複雑ではないはずです。そのようなタイプの複雑さはサーバー側でより適切に処理されるようだからです。
そうは言っても、javascript用のSOAPクライアントがいくつかあります。 jQueryにはそれがあります。したがって、SOAP できる JavaScriptから活用されます。 JSON文字列を返すRESTサービスほど良くありません。したがって、任意の数のクライアントテクノロジーと用途に柔軟に対応できるほど複雑になりたいWebサービスがある場合は、SOAPを使用します。
RESTを最初に使用することをお勧めします-Javaを使用している場合は、JAX-RSと Jersey の実装を確認してください。 RESTは、多くの言語で相互運用がはるかに簡単で簡単です。
このスレッドで他の人が言ったように、SOAPの問題は、他のWS- *仕様が出てくるときの複雑さであり、WSDL、XSD、SOAPの間違った部分に迷い込むと、相互運用の問題が無数にあります。 WS-Addressingなど。
REST v SOAPの議論を判断する最良の方法は、インターネットで見ることです。Webスペース、Google、Amazon、eBay、Twitterなどのほとんどすべての大物プレーヤーが傾向があります。 SOAPのRESTful APIよりもRESTful APIを使用し、優先します。
RESTを使用するもう1つの素晴らしいアプローチは、WebアプリケーションとRESTフロントエンドの間で多くのコードとインフラストラクチャを再利用できることです。例えばリソースのHTML、XML、JSONのレンダリングは通常、JAX-RSや暗黙的なビューなどのフレームワークで非常に簡単です。さらに、Webブラウザーを使用してRESTfulリソースを簡単に操作できます。
ドンボックスは冗談としてSOAPを作成したと確信しています-「見てくださいcan Web経由でRPCメソッドを呼び出す」になった ：-）
RESTは優れた、シンプルな、あらゆる場所（標準よりも「標準」）で迅速かつ簡単に実装されます。 RESTを使用します。
どちらにも独自の場所があると思います。私の考えでは：
SOAP：WS- *が意味をなす基礎層（セキュリティ、ポリシーなど）で、レガシー/クリティカルシステムとWeb/Webサービスシステムとの統合に適した選択肢。
RESTful：パブリックAPIを使用したWebサイト間の統合には、レイヤーの最上部（VIEW、つまり、URIを呼び出すJavaScript）を選択する方が適切です。
言及されていないことの1つは、SOAPエンベロープに本文部分だけでなくヘッダーも含めることができることです。これにより、XMLの完全な表現力を使用して、帯域外情報を送受信できます。 RESTは、私が知る限り、HTTPヘッダーと結果コードに制限しています。
（それでは、RESTサービスでCookieを使用して、「ヘッダー」タイプの帯域外データを送信できますか？）
XML-RPCを見落とさないでください。軽量なソリューションを求めている場合は、数ページのテキストで定義し、最小限のコードで実装できるプロトコルについて多くのことを言う必要があります。 XML-RPCは何年も前から存在していましたが、しばらくの間流行していませんでしたが、ミニマリストの魅力は最近の復活のようなものを与えているようです。
微妙です。
他のシステムとサービスとのインターフェースが必要な場合、契約、WSDL、およびSOAP標準に関する「検証」の層があるため、多くのクライアントがSOAPに満足しています。
システムを呼び出す日々のシステムの場合、SOAPは、単純なHTML呼び出しが行うときの多くの不必要なオーバーヘッドだと思います。
私は同じを見ています、そして、私は思う、それらは異なる問題のための異なるツールです。
メッセージアーキテクチャとメッセージ形式を定義するXML言語であるSOAP（Simple Object Access Protocol）標準は、操作の説明を含むWebサービスで使用されます。 WSDLは、Webサービスとそのアクセス方法を記述するためのXMLベースの言語です。 SMTP、HTTP、FTPなどで実行されます。WSDL+ XSDなどのサービスを定義するには、ミドルウェアサポート、明確に定義されたメカニズムが必要です。WS-PolicySOAPは、XMLベースのデータを返しますSOAPセキュリティと信頼性
Representational State Transfer（RESTful）Webサービス。これらは第2世代のWebサービスです。 RESTful Webサービス。SOAPベースのサービスよりもHTTP経由で通信し、XMLメッセージやWSDLサービスAPI定義を必要としません。 RESTにはミドルウェアは必要ありません。HTTPサポートのみが必要です。WADL標準、RESTはXML、プレーンテキスト、JSON、HTMLなどを返すことができます
多くのタイプのクライアントがRESTful Webサービスを利用しやすくする一方で、サーバー側の進化と拡張を可能にします。クライアントは、サービスの一部またはすべての側面を消費し、他のWebベースのサービスとマッシュアップすることを選択できます。
- RESTは標準HTTPを使用するため、クライアントの作成、APIの開発が簡単です
- RESTは、XML、プレーンテキスト、JSON、HTMLなどのさまざまなデータ形式を許可しますが、SOAPはXMLのみを許可します。
- RESTの方がパフォーマンスとスケーラビリティが優れています。
- 残り、キャッシュでき、SOAPはできません
- SOAPにエラー処理がないビルトインエラー処理
- RESTは、PDAおよびその他のモバイルデバイスで特に役立ちます。
REST isサービスは、既存のWebサイトと簡単に統合できます。
SOAPには、セキュリティと信頼性などの標準を提供するプロトコルセットがあり、他のWS準拠のクライアントおよびサーバーと相互運用できます。 SOAP Webサービス（JAX-WSなど）は、非同期処理と呼び出しの処理に役立ちます。
Complex APIの場合、SOAPがより便利です。
RESTはRoy Fieldingによって発明されたアーキテクチャであり、彼の論文で説明されています アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計 。 Royは HTTP -World Wide Web上のドキュメント転送を定義するプロトコルの主な著者でもあります。 HTTPはRESTfulプロトコルです。開発者が「REST Webサービスの使用」について話すとき、おそらく「HTTPを使用する」と言う方が正確です。
SOAPは、HTTP要求/応答内でトンネリングするXMLベースのプロトコルです。したがって、SOAPを使用している場合でも、RESTも使用しています。 SOAPが基本的なHTTPに重要な機能を追加するかどうかについては、いくつかの議論があります。
Webサービスを作成する前に、HTTPを学ぶことをお勧めします。おそらく、仕様で既に定義されている機能を使用して要件を実装できるため、他のプロトコルは必要ありません。
私は同じ問題を見ています。実際、RESTは、迅速かつ簡単で、軽量の呼び出しと応答に適し、デバッグに最適です（ブラウザーにURLを送り込んで応答を確認するよりも優れていると思われます）。
ただし、RESTが落ちているように見えるのは、それが標準ではないという事実に関係しています（ただし、標準で構成されています）。ほとんどのプログラミングライブラリには、WSDLを検査して、SOAPベースのサービスを使用するために必要なクライアントコードを自動的に生成する方法があります。これまでRESTベースのWebサービスを使用することは、可能な呼び出しに一致するインターフェースを記述する、よりアドホックなアプローチのようです。手動のHTTP要求を作成し、応答を解析します。これ自体は危険です。
SOAPの長所は、WSDLが発行されると、ビジネスのインターフェイスを変更してwsdlを変更するロジックを構築できることです。手入れの余地はありません。そのWSDLに対してすべてのリクエストを検証できます。ただし、WSDLはRESTサービスを適切に記述しないため、通信用のインターフェースに同意する方法が定義されていません。
ビジネスの観点からすると、これはコミュニケーションを解釈や変更に対して開かれたままにしているように見えますが、これは悪い考えのようです。
このスレッドの一番上の「回答」はSOAPがSimple Object-oriented Access Protocolを表しているように見えますが、wikiを見るとOはオブジェクト指向ではないオブジェクトを意味します。それらは異なるものです。
私はこの投稿が非常に古いことを知っていますが、私自身の発見で答えるべきだと思いました。
それは良い質問です...私はあなたを惑わしたくありませんので、私はあなたと同じくらい他の人の答えにオープンです。私にとっては、実際にはオーバーヘッドのコストとAPIの使用にかかっています。クライアントソフトウェアの作成時にWebサービスを使用することを好みますが、SOAPの重みは好きではありません。 RESTはより軽量であると信じていますが、クライアントの観点からすると、RESTを扱うのはあまり好きではありません。
他の人がどう思うか興味があります。
このポッドキャスト を聞いて調べてください。あなたが聞かないで答えを知りたいなら、OK、そのREST。しかし、私は本当に聞くことをお勧めします。
私の一般的なルールは、ブラウザWebクライアントをサービスに直接接続する場合、おそらくRESTを使用することです。バックエンドサービス間で構造化データを渡す場合は、SOAPを使用します。
SOAPは、セットアップするのが非常に面倒な場合があり、多くの場合、単純なWebクライアントおよびサーバーのデータ交換には過剰です。残念ながら、私が見た（そして学んだ）最も単純なプログラミング例は、この認識をいくらか強化しています。
そうは言っても、データワークフローによって推進されるより大きなプロセスの一部として複数のSOAPサービスを組み合わせて開始すると、SOAPは本当に輝いています（エンタープライズソフトウェアを考えてください）。これは、多くのSOAPプログラミング例では伝えられないことです。なぜなら、単純にSOAP操作を行うと、株価を取得するなどの操作が一般的に複雑になり、それ自体は、より大きなプロセスによってスクリプト化される入力と出力の設定データ形式で特定の機能を詳述する機械可読APIを提供するという文脈で提示されない限り、それ自体です。
SOAPの利点を最終製品の完全なコンテキストで提示せずに示すことは困難であるため、SOAPの評判が悪くなるため、これはある意味悲しいことです。使用されている。
「PHP-universe」PHPの意味で、高度なSOAPのサポートは非常に時間がかかります。 WS-SecurityやWS-を有効にする場合でも、基本的なニーズを超えるとすぐに http://wso2.com/products/web-services-framework/php/ のようなものを使用することになります。 RMサポートなし。
SOAPエンベロープの作成は、PHPでは非常に厄介であり、名前空間、xsd：nil、xsd：anytype、およびSOAPでSOAPエンコーディングを使用する古いスタイルのSOAPサービスを作成する方法]メッセージ。
RESTにこだわることで、この混乱をすべて避けてください。RESTは、WWWの開始以来使用してきた大きなものではありません。 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm の論文が出てきたときだけ、HTTP機能を使用してRESTFulサービスを実装する方法を示しています。 HTTPは本質的にRESTであり、HTTPを使用するだけでサービスがRESTFulになるわけではありません。
SOAPはHTTPのコア機能を無視し、HTTPをトランスポートプロトコルと見なします。したがって、理論上はトランスポートプロトコルに依存しません（実際には、SOAPアクションヘッダーについて聞いたことがありますか？ 。
JSONの適応が増加し、JavaScriptを使用するHTML5がJSONで成熟するRESTがサービスを処理する最も一般的な方法になりました。 JSONスキーマも定義されており、必要に応じてWADLとともにエンタープライズレベルのソリューション（まだ初期段階）に使用できます。
RESTおよびJSONのPHPサポートは、既存の組み込みのSOAPサポートよりも確実に優れています。
ここにいくつかのBUZZワードを追加しますSOA、WOA、ROA
http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/
http://www.scribd.com/doc/15657444/REST-White-Paper
特にWS-Security仕様のSOAPが大好きです。これは1つの優れた仕様であり、エンタープライズJSON適応を考えている人がフィールドレベルの暗号化など、JSONに似たものを明確に用意する必要がある場合.
SOAP Webサービスへのサービス指向のアプローチを実現します。メソッド（または動詞）がサービスと対話する主要な方法です。 RESTは、オブジェクト（または名詞）が中心となるリソース指向のアプローチを取ります。
1つの簡単なポイント-送信プロトコルとオーケストレーション。
オーケストレーションされたマシンツーマシンサービス（ESB）や外部サービスなど、速度、信頼性、セキュリティ上の理由から、SOAP over TCPを使用しています。サービス定義を変更すると、オーケストレーションはWSDLの変更からエラーを生成し、すぐに明らかになり、再構築/デプロイできます。
RESTでも同じことができるかどうかはわかりません-修正されるか、コースが完了するのを待ちます！ RESTを使用して、サービス定義を変更します-400（または何でも）を返すまで、サービス定義は何も知りません。
異なるシステムや言語間の相互運用性を探しているなら、私は間違いなくRESTに行きます。たとえば、.NETとJavaの間でSOAPを動作させようとすると、多くの問題が発生しました。
どれがより速いかを見つけるためのベンチマークを作成します私はこの結果を見ます：
1000リクエストの場合：
- RESTは3秒かかりました
- SOAPは7秒かかりました
10,000リクエストの場合：
- RESTは33秒かかりました
- SOAPは69秒かかりました
1,000,000リクエストの場合：
- RESTは62秒かかりました
- SOAPは114秒かかりました
古い質問ですが、今日でもまだ関連しています....まだエンタープライズスペースの多くの開発者が使用しているためです。
私の仕事には、IoT（モノのインターネット）ソリューションの設計と開発が含まれます。これには、クラウドと通信する小さな組み込みデバイス用のコードの開発が含まれます。
RESTが広く受け入れられ、有用になり、Azure全体にRESTサポートが含まれている場合でも、Webの事実上の標準であることが明らかです。 SOAPに依存する必要がある場合、小さな組み込みデバイスでは大きすぎてかさばり、迷惑なため、必要なことを実行できませんでした。
RESTはシンプルでクリーンで小さいです。小型の組み込み機器に最適です。 WSDLを送信するWeb開発者と作業しているとき、私はいつも悲鳴を上げます。私はこれがなぜうまくいかないのか、そしてなぜ彼らがRESTを学ばなければならないのかについての教育キャンペーンを始めなければならないので。
1.私の経験から。 RESTは、すでに構築されているURLにアクセスするオプションを提供すると言います。例-> GoogleでのWord検索。そのURLは、RESTのWebサービスとして使用できます。 SOAPでは、独自のWebサービスを作成し、SOAPクライアントを介してアクセスできます。
- RESTは、テキスト、JSON、XML形式をサポートしています。したがって、2つのアプリケーション間で通信するための汎用性が高まります。 SOAPは、メッセージ通信でXML形式のみをサポートします。