RESTはWebサービスを実行するためのより良いアプローチですか、それともSOAPですか？または、それらは異なる問題のための異なるツールですか？それとも微妙な問題ですか？つまり、特定のアリーナでは他のアリーナよりも少し優れていますか？

私は特に、それらの概念、およびそれらのPHPユニバースと最新のハイエンドWebアプリケーションとの関係についての情報をいただければ幸いです。

Hewlett-Packardで働いていたときに開発された元の仕様から、コード生成とWSDL生成を含む最初のSOAPサーバーの1つを構築しました。SOAPを使用することはお勧めしません。

頭字語「SOAP」は嘘です。それは単純ではなく、オブジェクト指向ではなく、アクセスルールを定義していません。間違いなく、プロトコルです。それはドン・ボックスの史上最悪のスペックであり、彼が「COM」を犯した男なので、それはかなりの偉業です。

SOAPでは、トランスポートのためにRESTで実行できず、データ表現のためにJSON、XML、またはプレーンテキストでさえ実行できない便利なものはありません。トランスポートのセキュリティには、httpsを使用できます。認証の場合、基本認証。セッションにはクッキーがあります。RESTバージョンは、よりシンプルで明確になり、実行が速くなり、使用する帯域幅が少なくなります。

XML-RPCは要求、応答、およびエラーのプロトコルを明確に定義しており、ほとんどの言語に適したライブラリがあります。ただし、XMLは多くのタスクに必要なものよりも重いです。

RESTはアーキテクチャであり、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はXMLを渡すことで通信するより複雑なAPIです。どちらにも長所と短所がありますが、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アプローチでは、開発者がこのカスタムプラミングを構築できます。

http://www.infoq.com/articles/rest-soap-when-to-use-each

SOAPには現在、優れたツールの利点があり、サービス層と特定のWSDLからクライアントを生成するための定型コードの多くを生成します。

RESTはシンプルで、結果として保守が容易で、Webアーキテクチャの中心にあり、プロトコルの可視性を向上させ、WWW自体のサイズで拡張できることが実証されています。Ruby on RailsなどのRESTサービスの構築に役立つフレームワークや、ADO.NET Data Servicesなどのクライアントの記述に役立つフレームワークもあります。しかし、ほとんどの場合、ツールのサポートが不足しています。

WSDLはツールによって非常に簡単に消費されるため、SOAPはツールの観点から有用です。そのため、お好きな言語でWebサービスクライアントを生成できます。

RESTはAJAXのWebページでうまく機能します。リクエストをシンプルに保つと、JavaScriptから直接サービスを呼び出すことができ、非常に便利です。応答XMLに名前空間を持たないようにしてください。ブラウザーがそれらを詰まらせるのを見てきました。したがって、xsi：typeはおそらく機能しません。過度に複雑なXMLスキーマはありません。

RESTのパフォーマンスも向上する傾向があります。REST応答を生成するコードのCPU要件は、SOAPフレームワークが示すものよりも低くなる傾向があります。また、XML生成アヒルがサーバー側に並んでいる場合は、XMLをクライアントに効率的にストリーミングできます。したがって、データベースカーソルの行を読み取っていると想像してください。行を読み取るときに、それをXML要素としてフォーマットし、それをサービスコンシューマーに直接書き出します。この方法では、XML出力の書き込みを開始する前に、メモリ内のすべてのデータベース行を収集する必要はありません。同時に読み取りと書き込みを行います。RESTでストリーミングを機能させるには、新しいテンプレートエンジンまたはXSLTを調べてください。

一方、SOAPは、ツールによって生成されたサービスによって大きなblobとして生成され、その後書き込まれる傾向があります。添付ファイルを使用するなど、SOAPからストリーミング特性を取得する方法はいくつかあります。

私の意思決定プロセスは次のとおりです。サービスを消費者が簡単にツール化できるようにしたい場合、書き込むメッセージは中小（10MB以下）であり、余分なCPUを焼いてもかまわないサーバー上のサイクル、私はSOAPで行きます。WebブラウザーでAJAXに対応する必要がある場合、またはストリーミングするものが必要な場合、または応答が非常に大きい場合は、RESTを使用します。

最後に、SOAPに関しては、WS-SecurityやステートフルなWebサービスの取得など、適切なツールを使用している場合にプラグインできる、多くの優れた標準が構築されています。この種のものは本当に違いをもたらし、いくつかの毛深い要件を満たすのに役立ちます。

これは古い質問であることはわかっていますが、回答を投稿する必要があります。SOAPよりもRESTを推奨している人がどれほどいるのか、私には信じられません。私は、これらの人々が開発者ではないか、妥当なサイズのRESTサービスを実際に実装したことがないと仮定することができます。RESTサービスの実装は、SOAPサービスの実装よりも長い時間がかかります。そして結局、それもかなり厄介なことになります。99％の確率でSOAPを選択する理由は次のとおりです。

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にそれがあることを知っています。したがって、JavaScriptからSOAPを利用できます。JSON文字列を返すRESTサービスほどうまくいきません。したがって、任意の数のクライアントテクノロジーと使用に柔軟に対応できるほど複雑にしたいWebサービスがある場合、SOAPを使用します。

最初にRESTを使用することをお勧めします。Javaを使用している場合は、JAX-RSおよびJerseyを参照してください。実装を確認してください。RESTは多くの言語で非常にシンプルで相互運用が容易です。

他のスレッドがこのスレッドで述べたように、SOAPの問題は、他のWS- *仕様が導入されたときの複雑さであり、WSDL、XSD、SOAP、WS-Addressingなどの誤った部分に迷惑をかけた場合、無数の相互運用性の問題があります。

RESTとSOAPの討論を判断する最良の方法は、インターネットで見ることです。Webスペース、グーグル、アマゾン、ebay、ツイッターなどの大部分のプレーヤーは、SOAPのAPIよりもRESTfulのAPIを使用して好む傾向があります。

RESTを使用するもう1つの優れたアプローチは、WebアプリケーションとRESTフロントエンドの間で多くのコードとインフラストラクチャを再利用できることです。たとえば、リソースのHTML対XML対JSONのレンダリングは、JAX-RSや暗黙のビューなどのフレームワークを使用すると、通常はかなり簡単です。さらに、Webブラウザーを使用してRESTfulリソースを操作するのも簡単です。

ドンボックスが冗談としてSOAPを作成したと私は確信しています-「Web経由でRPCメソッドを呼び出すことができるように見える」そして今日、彼がWeb標準の肥大化した悪夢に気づくとうめきます:-)

RESTは素晴らしく、シンプルで、どこにでも実装されているため（標準よりも「標準」であり）、高速で簡単です。RESTを使用します。

どちらにも独自の立場があると思います。私の考えでは：

SOAP：WS- *が意味を持つ基盤レイヤー（セキュリティ、ポリシーなど）での、レガシー/クリティカルシステムとWeb / Webサービスシステム間の統合のためのより良い選択。

RESTful：パブリックAPIを使用して、レイヤーのトップ（VIEW、つまり、URIへの呼び出しを行うJavaScript）でWebサイト間の統合を行うためのより良い選択。

言及されていないことの1つは、SOAPエンベロープにヘッダーと本文部分を含めることができることです。これにより、XMLの完全な表現力を使用して、帯域外情報を送受信できます。RESTは、私の知る限り、HTTPヘッダーと結果コードに制限しています。

（Otoh、RESTサービスでCookieを使用して「ヘッダー」タイプの帯域外データを送信できますか？）

XML-RPCを見落とさないでください。軽量ソリューションの直後であれば、2、3ページのテキストで定義でき、最小限のコードで実装できるプロトコルについて、多くのことが言えるでしょう。XML-RPCは何年も前から存在していますが、しばらくの間流行していませんでした。

2012年の更新された（2番目の賞金で）質問に答え、今日の結果を確認します（その他の回答）。

SOAP、長所と短所

SOAP 1.2について、「REST」と比較した場合の利点と欠点... 2007年以降、 REST WebサービスをWSDLで記述し、SOAPプロトコルを使用できるようになりました...つまり、もう少し頑張れば、すべてのW3C標準WebサービスプロトコルスタックはRESTにすることができます。

哲学的および方法論的な議論がすべて一時的に回避されるシナリオを想像できるため、これは良い出発点です。同様のサービスで技術的に「SOAP-REST」と「NON-SOAP-REST」を比較できます。

• SOAP-REST（= "REST-SOAP"）：L.Mandelで示されているように、WSDL2はREST Webサービスを記述できます。また、例示されたXMLをSOAPでエンベロープできると仮定すると、すべての実装は "SOAP-REST"になります。 。

• NON-SOAP-REST：SOAPにできないREST Webサービス...つまり、有名なRESTの例の「90％」。XMLを使用しないもの（通常のAJAX RESTは代わりにJSONを使用するものなど）、SOAPヘッダーやルールなしで別のXML構造を使用するものもあります。PS：非公式を避けるために、比較ではRESTレベル2を想定できます。

もちろん、より概念的に比較するには、異なるモデリングアプローチとして、「NON-REST-SOAP」と「NON-SOAP-REST」を比較します。したがって、このWebサービスの分類法を完成させます。

• NON-REST-SOAP：RESTにできないSOAP Webサービス...つまり、有名なSOAPサンプルの「90％」です。

• 非REST-NEITHER-SOAP：はい、「Webサービスモデリング」の世界は他のもので構成されています（例：XML-RPC）。

RESTコンディションにおけるSOAP

比較可能なものの比較：SOAP-RESTとNON-SOAP-REST。

長所

いくつかの用語を説明し、

• 契約の安定性：あらゆる種類の契約（「書面による合意」として）、

  • 標準を使用することにより、W3Cスタックのすべてのレベル が相互に準拠します。一方、RESTはW3CまたはISO標準ではなく、サービスの周辺機器に関する標準化された詳細はありません。したがって、私と同様に、@ DaveWoldrich（20票）、@ cynicalman（5）、@ Exitos（0）は前に述べましたが、標準が必要なコンテキストでは、SOAPが必要です。

  • ベストプラクティスを使用することにより、W3Cスタック実装の「冗長な側面」により、関連する人間/法的/法的合意を変換します。

• 堅牢性：SOAP構造とヘッダーの安全性。metada通信（XMLの完全な表現力）と検証により、変更やノイズに対する「保険ポリシー」があります。
  SOAPは、「トランザクションの信頼性（...）が通信障害に対処します。SOAPは再試行ロジックに関する制御が多いため、エンドツーエンドの信頼性とサービスの保証を提供できます」、E。Terman。

人気でプロを並べ替え、

• 優れたツール（〜70票）：SOAPは、2007年から2012年にかけて、明確に定義され広く受け入れられている標準であるため、現在は優れたツールという利点があります。@MarkCidade（27票）、@ DaveWoldrich（20）、@ JoshM（13）、@ TravisHeseman（9）を参照してください。

• 標準への準拠（25票）：I、@ DaveWoldrich（20票）、@ cynicalman（5）、@ Exitos（0）が以前に述べたように、標準が必要なコンテキストでは、SOAPが必要です。

• 堅牢性：SOAPヘッダーの保険、@ JohnSaunders（8票）。

短所

• SOAPの構造はより複雑です（300票以上）。ここでのすべての回答と、「SOAP vs REST」に関する情報源は、SOAPの冗長性と複雑さにある程度の嫌悪感を示しています。これは、正式な検証（下記を参照）および堅牢性（上記を参照）の要件の当然の帰結です。"REST NON-SOAP"（およびXML-RPC、SOAPオリジネーター）は、よりシンプルで非公式にすることができます。

• 「XMLのみ」の制限は、小さなサービス（50票まで）を使用する場合のパフォーマンスの障害です。json.org / xml とこの質問、またはこの他の質問を参照してください。この点は、@ toluju（41）などによって示されています。
  PS：JSONはIETF標準ではありませんが、 Webソフトウェアコミュニティの事実上の標準と考えることができます。

SOAPを使用したサービスのモデリング

ここで、SOAP-NON-RESTとNON-SOAP-RESTの比較を追加し、SOAP を使用する方が適切な場合について説明します。

• 標準と安定した契約の必要性（「PROS」セクションを参照）。PS：@sailleによって記述された典型的な「標準に対するB2Bの必要性」を参照してください。

• ツールの必要性（「PROS」セクションを参照）。PS：標準、および正式な検証（以下を参照）の存在は、ツールの自動化にとって重要な問題です。

• 並列処理（以下の「コンテキスト/ファンデーション」セクションを参照）：SOAPが多少複雑になっても、プロセスが大きくなったり遅くなったりすると、信頼性と安定性が最善の投資になります。

• より多くのセキュリティが必要：HTTPS以外のものが必要で、保護のための追加機能が本当に必要な場合は、SOAPがより良い選択です（@Bellを参照、32票）。"要求/応答よりも複雑なパスに沿って、またはHTTPを使用しないトランスポートを介してメッセージを送信する"、S。Seely。XMLは中核的な問題であり、XML暗号化、XML署名、およびXML正規化の標準を提供します。また、これらのメカニズムをSOAPでのみ、WS-Securityとして広く受け入れられている標準によってメッセージに埋め込むことができます。

• より柔軟性が必要（制限が少ない）：SOAPはURIとの正確な対応を必要としません。HTTPに制限されていない; 4つの動詞に制限する必要はありません。@TravisHeseman（9票）が言うように、「任意の数のクライアントテクノロジーと使用に柔軟に対応できる」何かが必要な場合は、SOAPを使用してください。
  PS：XMLはJSON（その他）よりも普遍的/表現力があることを忘れないでください。

• 正式な検証の必要性：W3Cスタックは正式なメソッドを使用し、RESTはより非公式であることを理解することが重要です。WSDL（正式な言語）サービスの説明は、 Webサービスインターフェイスの正式な仕様であり、SOAPは、可能なすべてのWSDL規定を受け入れる堅牢なプロトコルです。

環境

歴史的

傾向を評価することは必要な歴史的展望です。このテーマについて、10年または15年の展望...

W3C標準化の前に、いくつかの無秩序があります。異なるフレームワークで相互運用可能なサービスを実装することは困難であり、企業間で相互運用可能な何かを実装することはより困難で、コストと時間がかかりました。W3Cスタック規格、複雑なWebサービスのセットの相互運用のための北の光となっています。

AJAXを実装するような日々のタスクでは、SOAPは重いです...したがって、シンプルなアプローチの必要性は、新しい理論フレームワークを選出する必要があります...そして、Google、Amazonなどの大きな「Webソフトウェアプレーヤー」 Yahoo他は、RESTアプローチである最良の選択肢を選びました。RESTの概念が「競合するフレームワーク」として到着したのはこのような状況であり、今日（2012年代）、この代替案は事実上の標準ですプログラマーにとってです。

財団

並列コンピューティングのコンテキストでは、Webサービスは並列サブタスクを提供します。SOAPなどのプロトコルは、適切な同期と通信を保証します。「任意のタスク」ではない：Webサービスは、
粗粒度で厄介な並列処理として分類できます。

タスクが大きくなるにつれて、それは重要性の低い「複雑さの議論」になり、コミュニケーションの堅牢性と契約の強固さの関連性が高まります。

それは微妙です。

サービスと他のシステムとのインターフェースが必要な場合、コントラクト、WSDL、およびSOAP標準を使用する「検証」のレイヤーにより、多くのクライアントがSOAPに満足します。

システムを呼び出す日常のシステムの場合、単純なHTML呼び出しを行う場合、SOAPは多くの不要なオーバーヘッドであると思います。

私は同じものを見ているのですが、 それらはさまざまな問題に対するさまざまなツールです。

Simple Object Access Protocol（SOAP）標準は、メッセージアーキテクチャとメッセージフォーマットを定義するXML言語であり、操作の説明を含むWebサービスによって使用されます。WSDLは、Webサービスとそのアクセス方法を説明するためのXMLベースの言語です。SMTP、HTTP、FTPなどで実行されます。ミドルウェアサポート、WSDL + XSDなどのサービスを定義するための明確に定義されたメカニズムが必要です。WS-PolicySOAPはXMLベースのデータを返しますSOAPはセキュリティと信頼性の標準を提供します

表現状態転送（RESTful）Webサービス。これらは第2世代のWebサービスです。RESTful Webサービス。SOAPベースのサービスよりもHTTP経由で通信し、XMLメッセージやWSDLサービスAPI定義を必要としません。RESTの場合、ミドルウェアは不要で、HTTPサポートのみが必要です。WADL標準、RESTは、XML、プレーンテキスト、JSON、HTMLなどを返すことができます。

多くのタイプのクライアントがRESTful Webサービスを利用するのは簡単ですが、サーバー側の進化とスケーリングを可能にします。クライアントは、サービスの一部またはすべての側面を利用し、他のWebベースのサービスとマッシュアップすることを選択できます。

1. RESTは標準のHTTPを使用するため、クライアントの作成やAPIの開発が簡単です
2. RESTは、XML、プレーンテキスト、JSON、HTMLなどの多くの異なるデータ形式を許可しますが、SOAPはXMLのみを許可します。
3. RESTはパフォーマンスとスケーラビリティが優れています。
4. 残りの部分はキャッシュでき、SOAPはできません
5. SOAPにエラー処理がない組み込みエラー処理
6. RESTは特に便利なPDAおよびその他のモバイルデバイスです。

RESTは、既存のWebサイトと簡単に統合できるサービスです。

SOAPには、特にセキュリティと信頼性の標準を提供し、他のWS準拠のクライアントおよびサーバーと相互運用する一連のプロトコルがあります。SOAP Webサービス（JAX-WSなど）は、非同期処理と呼び出しの処理に役立ちます。

Complex APIのSOAPの方が便利です。

RESTは、ロイフィールディングによって発明されたアーキテクチャであり、彼の論文のArchitectural Styles and the Design of Network-based Software Architecturesで説明されています。RoyはHTTPの主要な作者でもあります World Wide Webを介したドキュメント転送を定義するプロトコル）ます。HTTPはRESTfulプロトコルです。開発者が「REST Webサービスの使用」について話すとき、「HTTPの使用」と言う方がおそらくより正確です。

SOAPは、HTTP要求/応答内でトンネリングするXMLベースのプロトコルであるため、SOAPを使用していてもRESTを使用しています。SOAPが基本的なHTTPに重要な機能を追加するかどうかについては、いくつかの議論があります。

Webサービスを作成する前に、HTTPについて学習することをお勧めします。おそらく、仕様にすでに定義されている機能を使用して要件を実装できるため、他のプロトコルは必要ありません。

私は同じ問題を見ています。実際、RESTは迅速かつ簡単で軽量の呼び出しと応答に優れており、デバッグに優れているようです（ブラウザーにURLを送り込んで応答を確認するよりも優れている点があります）。

ただし、RESTが落ちるように見えるのは、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を操作することはあまり好きではありません。

他の人がどう思うか知りたいです。

このポッドキャストを聞いて調べてください。聞くことなく答えを知りたい場合は、そのRESTを使用します。しかし、私は本当に聞くことをお勧めします。

私の一般的なルールは、ブラウザーのWebクライアントをサービスに直接接続する場合は、おそらくRESTを使用することです。バックエンドサービス間で構造化データを渡す場合は、SOAPを使用します。

SOAPは、セットアップが非常に面倒な場合があり、単純なWebクライアントとサーバーのデータ交換にとってはやりすぎです。残念ながら、私が見た（そしてそれから学んだ）最も単純なプログラミングの例は、この認識をいくらか強化しています。

つまり、SOAPは、データワークフロー（エンタープライズソフトウェアを考える）によって駆動されるより大きなプロセスの一部として複数のSOAPサービスを結合し始めると、本当に素晴らしいものになります。これは、多くのSOAPプログラミング例では伝えられないことです。これは、株価を取得するなど、何かを行う単純なSOAP操作は、マシンを提供するコンテキストで提示されない限り、通常、それ自体で行うことに対して過度に複雑です。入力と出力のデータ形式が設定された特定の関数の詳細を示す、読み取り可能なAPI。詳細なプロセスによってスクリプト化されます。

最終製品がどのように使用されているかを完全に説明することなくSOAPの利点を示すことは難しいため、SOAPの評判が悪いため、これは悲しいことです。

SOAPは Webサービスへのサービス指向のアプローチを具体化します。その1つは、メソッド（または動詞）がサービスと対話する主要な方法です。RESTは、オブジェクト（または名詞）が中心となるリソース指向のアプローチを採用しています。

「PHPユニバース」という意味では、高度なSOAPのPHPサポートは非​​常に時間がかかります。WS-SecurityまたはWS-RMの組み込みサポートが有効になっていなくても、基本的なニーズを満たせばすぐにhttp://wso2.com/products/web-services-framework/php/のようなものを使用することになります。

SOAPエンベロープの作成は、PHPでは非常に面倒で、SOAPメッセージでSOAPエンコーディングを使用するネームスペース、xsd：nil、xsd：anytype、および古いスタイルのSOAPサービスを作成します（神はその違いを知っています）。

RESTに固執することで、この混乱をすべて回避します。RWは、WWWの開始以来、私たちがRESTを使用してきた大きなものではありません。この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に似たものを明確に必要とする場合は、

ワンポイント-伝送プロトコルとオーケストレーション。

速度、信頼性、およびセキュリティ上の理由から、オーケストレーションされたマシンツーマシンサービス（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が広く受け入れられて便利になったことは明らかで、MicrosoftでもAzure全体にRESTサポートが含まれているにもかかわらず、Webの事実上の標準となっています。SOAPに依存する必要がある場合は、必要なことを実行できませんでした。これは、小さな組み込みデバイスでは大きすぎ、かさばり、煩わしいためです。

RESTはシンプルでクリーンで小さいです。小型の組み込み機器に最適です。WSDLを送ってくれるWeb開発者と一緒に仕事をしているときはいつも絶叫します。私はなぜこれがうまくいかないのか、なぜ彼らがRESTを学ぶ必要があるのか​​についての教育キャンペーンを始めなければならないでしょう。

1.私の経験から。RESTには、すでに構築されているURLにアクセスするオプションがあると思います。例->グーグルでの単語検索。そのURLはRESTのWebサービスとして使用できます。SOAPでは、独自のWebサービスを作成し、SOAPクライアントを通じてアクセスできます。

2. RESTはテキスト、JSON、XML形式をサポートしています。したがって、2つのアプリケーション間の通信に、より汎用性があります。SOAPはメッセージ通信でXML形式のみをサポートします。