REST は Web サービスを行うためのより良いアプローチですか、それとも SOAP ですか? それとも、さまざまな問題に対するさまざまなツールですか? それとも微妙な問題なのですか？つまり、特定のアリーナでは別のアリーナよりもわずかに優れているなどですか？
これらの概念と、PHP ユニバースおよび最新のハイエンド Web アプリケーションとの関係についての情報を特に感謝します。
質問する
122608 次
28 に答える
563
Hewlett-Packardで働いていたときに、開発中の元の仕様から、コード生成とWSDL生成を含む最初のSOAPサーバーの1つを構築しました。何かにSOAPを使用することはお勧めしません。
頭字語「SOAP」は嘘です。単純ではなく、オブジェクト指向ではなく、アクセスルールを定義していません。間違いなく、これはプロトコルです。これはドンボックスの史上最悪のスペックであり、彼は「COM」を実行した男であるため、それはかなりの偉業です。
トランスポート用のREST、およびデータ表現用のJSON、XML、さらにはプレーンテキストで実行できないSOAPには有用なものはありません。トランスポートセキュリティには、httpsを使用できます。認証については、基本認証。セッションにはCookieがあります。RESTバージョンは、よりシンプルで明確になり、実行速度が速くなり、使用する帯域幅が少なくなります。
XML-RPCは、要求、応答、およびエラープロトコルを明確に定義しており、ほとんどの言語に適したライブラリがあります。ただし、XMLは多くのタスクに必要なものよりも重いです。
于 2008-09-16T20:59:47.670 に答える
200
REST はアーキテクチャであり、SOAP はプロトコルです。
それが最初の問題です。
REST アプリケーションで SOAP エンベロープを送信できます。
SOAP 自体は実際には非常に基本的で単純ですが、SOAP を非常に複雑にしているのは、その上にある WSS-* 標準です。
コンシューマが他のアプリケーションや他のサーバーである場合、今日の SOAP プロトコルは多くのサポートがあり、データ移動の基本は基本的に最新の IDE でのマウス クリックです。
コンシューマが RIA または Ajax クライアントである可能性が高い場合は、SOAP よりも単純で、クライアントにとってよりネイティブなもの (特に JSON) が必要になるでしょう。
HTTP 経由で送信される JSON パケットは必ずしも REST アーキテクチャではなく、URL への単なるメッセージです。すべて完全に機能しますが、REST イディオムには重要なコンポーネントがあります。ただし、この 2 つを混同するのは簡単です。しかし、HTTP リクエストについて話しているからといって、必ずしも REST アーキテクチャがあるとは限りません。HTTP をまったく使用しない REST アプリケーションを使用することもできます (注意してください、これはまれです)。
そのため、SOAP に「慣れている」サーバーとコンシューマーがあれば、SOAP と WSS スタックはうまく機能します。よりアドホックなことを行っていて、Web ブラウザーとのインターフェースを改善したい場合は、HTTP を介した軽量のプロトコルもうまく機能します。
于 2008-09-16T20:37:56.753 に答える
102
REST は、SOAP とは根本的に異なるパラダイムです。REST に関する適切な読み物は、How I Explain REST to my wife にあります。
読む時間がない場合は、短いバージョンを次に示します。REST は、"名詞" に焦点を当て、それらの名詞に適用できる "動詞" の数を制限するという、少しパラダイム シフトです。使用できる動詞は、「get」、「put」、「post」、および「delete」のみです。これは、多くの異なる名詞に多くの異なる動詞を適用できる (つまり、多くの異なる関数) SOAP とは異なります。
REST の場合、4 つの動詞は対応する HTTP 要求にマップされ、名詞は URL によって識別されます。これにより、サーバーの状態とクライアントの状態が明確でないことが多い SOAP よりも、状態管理がはるかに透過的になります。
しかし実際には、このほとんどはなくなります。REST は通常、結果をJSONで返す単純な HTTP リクエストを参照するだけですが、SOAP は XML を渡すことによって通信するより複雑な API です。どちらにも長所と短所がありますが、私の経験では、SOAP から得られるすべての機能が必要になることはめったにないため、通常は REST がより良い選択であることがわかりました。
于 2008-09-16T20:42:10.427 に答える
59
2012年の質問の簡単な内訳：
REST が非常にうまく機能する分野は次のとおりです。
限られた帯域幅とリソース。戻り構造は実際には任意の形式 (開発者が定義) であることを忘れないでください。さらに、REST アプローチは標準の GET、PUT、POST、および DELETE 動詞を使用するため、任意のブラウザーを使用できます。繰り返しになりますが、REST は、現在のほとんどのブラウザーが現在サポートしている XMLHttpRequest オブジェクトも使用できることを思い出してください。これにより、AJAX の利点がさらに追加されます。
完全にステートレスな操作。 操作を継続する必要がある場合、REST は最善のアプローチではなく、SOAP の方が適している可能性があります。ただし、ステートレスな CRUD (作成、読み取り、更新、および削除) 操作が必要な場合は、REST が最適です。
キャッシングの状況。 RESTアプローチの完全ステートレスな運用で情報をキャッシュできれば完璧です。上記の3つで多くの解決策をカバーしています。
では、なぜ SOAP を検討する必要があるのでしょうか。繰り返しになりますが、SOAP はかなり成熟しており、明確に定義されており、完全な仕様が付属しています。REST アプローチはまさに 1 つのアプローチであり、開発に対して広く開かれているため、次のような場合、SOAP は優れたソリューションです。
非同期処理と呼び出し。 アプリケーションが保証されたレベルの信頼性とセキュリティを必要とする場合、SOAP 1.2 はこのタイプの操作を保証する追加の標準を提供します。WSRM – WS-Reliable Messaging のようなもの。
正式な契約。 両側 (プロバイダーとコンシューマー) が交換フォーマットに同意する必要がある場合、SOAP 1.2 はこのタイプの対話に対して厳格な仕様を提供します。
ステートフル操作。アプリケーションがコンテキスト情報と会話状態の管理を必要とする場合、SOAP 1.2 には WS* 構造に追加の仕様があり、それらをサポートします (セキュリティ、トランザクション、調整など)。比較すると、REST アプローチでは、開発者はこのカスタム プラミングを構築する必要があります。
于 2012-12-24T03:08:34.147 に答える
44
現在、 SOAPには、サービス層と任意の WSDL からクライアントを生成するためのボイラープレート コードを大量に生成する優れたツールという利点があります。
RESTはより単純で、結果として保守が容易になり、Web アーキテクチャの中心に位置し、プロトコルの可視性が向上し、WWW 自体のサイズに合わせて拡張できることが証明されています。Ruby on Rails などの REST サービスの構築に役立つフレームワークもあれば、ADO.NET Data Services などのクライアントの作成に役立つフレームワークもあります。しかし、ほとんどの場合、ツールのサポートが不足しています。
于 2008-09-16T20:36:37.723 に答える
40
WSDL はツールによって非常に簡単に使用されるため、SOAP はツールの観点から有用です。そのため、好みの言語で生成された Web サービス クライアントを取得できます。
REST は、AJAX の Web ページでうまく機能します。リクエストをシンプルにしておくと、JavaScript から直接サービスを呼び出すことができ、非常に便利です。応答 XML に名前空間を含めないようにしてください。ブラウザーがそれらで窒息するのを見てきました。したがって、過度に複雑な XML スキーマではなく、xsi:type はおそらく機能しません。
REST の方がパフォーマンスも優れている傾向があります。REST 応答を生成するコードの CPU 要件は、SOAP フレームワークが示すものよりも低くなる傾向があります。また、XML 生成のアヒルをサーバー側に配置している場合は、XML を効果的にクライアントにストリーミングできます。ですから、データベース カーソルの行を読んでいると想像してください。行を読み取るときに、それを XML 要素としてフォーマットし、それをサービス コンシューマーに直接書き込みます。この方法では、XML 出力の書き込みを開始する前に、メモリ内のすべてのデータベース行を収集する必要はありません。読み取りと書き込みを同時に行うことができます。REST でストリーミングを機能させるには、新しいテンプレート エンジンまたは XSLT を調べてください。
一方、SOAP は、ツールによって生成されたサービスによって大きな BLOB として生成されてから書き込まれる傾向があります。これは絶対的な真実ではありません。添付ファイルを使用するなど、SOAP からストリーミング特性を取得する方法があります。
私の意思決定プロセスは次のとおりです。消費者が自分のサービスを簡単に利用できるようにしたい場合、および私が書くメッセージは中規模から小規模 (10MB 以下) であり、余分な CPU を消費してもかまいません。サーバー上でのサイクル、私は SOAP を使用します。Web ブラウザーで AJAX にサービスを提供する必要がある場合、ストリーミングするものが必要な場合、または応答が巨大な場合は、REST を使用します。
最後に、WS-Security やステートフル Web サービスの取得など、適切なツールを使用している場合にプラグインできる、SOAP を中心に構築された優れた標準が多数あります。そのようなものは本当に違いを生み、いくつかの厄介な要件を満たすのに役立ちます.
于 2008-09-16T20:50:52.510 に答える
29
これは古い質問であることはわかっていますが、回答を投稿する必要があります。誰かが役に立つと思うかもしれません。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 を本当に気にしますか?
続ける必要がありますか？
于 2010-07-23T21:19:18.547 に答える
19
私が作成するアプリケーションのほとんどは、サーバー側のC＃またはJava、あるいはWinFormsまたはWPFのデスクトップアプリケーションです。これらのアプリケーションは、RESTが提供できるよりも豊富なサービスAPIを必要とする傾向があります。さらに、Webサービスクライアントの作成に数分以上費やしたくありません。WSDL処理クライアント生成ツールを使用すると、クライアントを実装して、ビジネス価値の追加に進むことができます。
さて、もし私がいくつかのjavascript ajax呼び出しのために明示的にWebサービスを書いていたら、それはおそらくRESTにあるでしょう。クライアントテクノロジーを知り、JSONを活用するためだけに。私の意見では、javascriptから使用されるWebサービスAPIは、おそらくそれほど複雑ではないはずです。そのような複雑さは、サーバー側でより適切に処理されるように思われるからです。
そうは言っても、javascript用のSOAPクライアントがいくつかあります。jQueryに1つあることは知っています。したがって、SOAPはjavascriptから利用できます。JSON文字列を返すRESTサービスほどうまくはありません。したがって、任意の数のクライアントテクノロジと使用に柔軟に対応できるように、十分に複雑にしたいと考えているWebサービスがある場合は、SOAPを使用します。
于 2009-09-22T15:36:38.087 に答える
17
最初にRESTを使用することをお勧めします。Javaを使用している場合は、JAX-RSとJerseyの実装を確認してください。RESTは、多くの言語ではるかに単純で相互運用が容易です。
他の人がこのスレッドで言っているように、SOAPの問題は、他のWS- *仕様が導入されたときの複雑さであり、WSDL、XSD、SOAP、WS-Addressingなどの間違った部分に迷い込んだ場合の相互運用の問題は無数にあります。
REST v SOAPの議論を判断する最良の方法は、インターネットを調べることです。ウェブスペース、グーグル、アマゾン、イーベイ、ツイッターなどのほとんどすべての大手企業は、SOAPよりもRESTfulAPIを使用して好む傾向があります。
RESTを使用するためのもう1つの優れたアプローチは、WebアプリケーションとRESTフロントエンドの間で多くのコードとインフラストラクチャを再利用できることです。たとえば、リソースのHTML対XML対JSONのレンダリングは、通常、JAX-RSや暗黙的なビューなどのフレームワークを使用すると非常に簡単です。さらに、Webブラウザーを使用してRESTfulリソースを簡単に操作できます。
于 2008-09-17T11:18:06.327 に答える
16
ドンボックスがジョークとしてSOAPを作成したと確信しています-「 Web上でRPCメソッドを呼び出すことができるように見えます」そして今日、彼がWeb標準の肥大化した悪夢に気づいたときにうめき声を上げます:-)
RESTは優れており、シンプルで、どこにでも（標準よりも「標準」として）すばやく簡単に実装できます。RESTを使用します。
于 2008-09-16T20:54:41.457 に答える
15
どちらにもそれぞれの居場所があると思います。私の意見では：
SOAP : レガシー/重要なシステムと Web/Web サービス システムを、WS-* が意味を成す (セキュリティ、ポリシーなど) 基盤層で統合するためのより良い選択です。
RESTful : Web サイト間の統合に適した選択肢で、パブリック API をレイヤーのトップ (ビュー、つまり、URI を呼び出す JavaScript) で使用します。
于 2011-11-21T15:57:23.413 に答える
13
言及されていないことの 1 つは、SOAP エンベロープにはヘッダーと本体部分を含めることができるということです。これにより、XML の完全な表現力を使用して、帯域外の情報を送受信できます。私の知る限り、REST は HTTP ヘッダーと結果コードに制限されています。
(おっと、REST サービスで Cookie を使用して、「ヘッダー」タイプの帯域外データを送信できますか?)
于 2009-08-19T09:51:20.060 に答える
10
XML-RPCを見落とさないでください。軽量のソリューションを求めているのであれば、数ページのテキストで定義し、最小限のコードで実装できるプロトコルについては、多くのことが言われています。XML-RPCは何年も前から存在していましたが、しばらくの間時代遅れになりました-しかし、ミニマリストの魅力は、最近の復活のようなものを与えているようです。
于 2008-09-16T20:34:58.587 に答える
10
2012 年に更新された (2 回目のバウンティによる) 質問への回答、および今日の結果のレビュー (その他の回答)。
SOAP、長所と短所
SOAP 1.2 について、「REST」と比較した場合の長所と短所.. さて、2007 年から、 REST Web サービスを WSDLで記述し、SOAP プロトコルを使用して記述できるようになりました. 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%」です。
NON-REST-NEITHER-SOAP : はい、「Web サービス モデリング」の世界は他のもの (例: XML-RPC ) で構成されています。
REST 条件での SOAP
同等のものの比較: SOAP-RESTとNON-SOAP-REST。
長所
いくつかの用語を説明すると、
契約の安定性: あらゆる種類の契約 (「書面による合意」として)、
堅牢性: SOAP 構造とヘッダーの安全性。メタデータ通信 (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 を使用した方がよいかを説明できます。
標準と安定した契約の必要性 (「長所」セクションを参照)。PS: @saille で説明されている典型的な「標準に対する B2B の必要性」を参照してください。
ツールの必要性(「PROS」セクションを参照)。PS:標準、および正式な検証(以下を参照) の存在は、ツールの自動化にとって重要な問題です。
並列の重い処理(以下の「コンテキスト/基盤」セクションを参照): 処理が大きくて遅くても、SOAP が多少複雑であっても、信頼性と安定性が最善の投資です。
より多くのセキュリティが必要 : HTTPS 以外のものが必要であり、保護のために追加機能が本当に必要な場合は、SOAP の方が適しています ( @Bell、32 票を参照)。「リクエスト/レスポンスよりも複雑なパスに沿ってメッセージを送信するか、HTTP を含まないトランスポートを介してメッセージを送信する」、S. Seely . XML は中心的な問題であり、XML Encryption、XML Signature、およびXML Canonicalizationの標準を提供します。また、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、 Yahoo などは、REST アプローチという最良の代替手段を選択しました。このコンテキストで、REST の概念が「競合するフレームワーク」として登場し、今日 (2012 年)、この代替案はプログラマーにとって事実上の標準となっています。
基礎
並列コンピューティングのコンテキストでは、Web サービスは並列サブタスクを提供します。また、SOAP などのプロトコルは、良好な同期と通信を保証します。「任意のタスク」ではありません。Web サービスは、
粗粒度の厄介な並列処理として分類できます。
タスクが大きくなるにつれて、「複雑さの議論」の重要性は低くなり、コミュニケーションの堅牢性と契約の堅実性がより重要になります。
于 2012-12-19T12:38:40.023 に答える
9
微妙です。
サービスと他のシステムのインターフェースが必要な場合、契約、WSDL、および SOAP 標準での「検証」のレイヤーにより、多くのクライアントは SOAP に満足します。
システムを呼び出す日常的なシステムでは、単純な HTML 呼び出しで十分な場合、SOAP は多くの不必要なオーバーヘッドになると思います。
于 2008-09-16T20:28:22.627 に答える
8
REST は Roy Fielding によって考案されたアーキテクチャであり、彼の論文Architectural Styles and the Design of Network-based Software Architecturesで説明されています。Roy は HTTP の主な作成者でもあります。HTTPは、World Wide Web を介したドキュメント転送を定義するプロトコルです。HTTP は RESTful プロトコルです。開発者が「REST Web サービスを使用する」ことについて話す場合、おそらく「HTTP を使用する」と言う方が正確です。
SOAP は、HTTP 要求/応答内でトンネリングする XML ベースのプロトコルであるため、SOAP を使用していても、REST も使用していることになります。SOAP が基本的な HTTP に重要な機能を追加するかどうかについては、いくつかの議論があります。
Web サービスを作成する前に、HTTP について学習することをお勧めします。仕様で既に定義されている機能を使用して要件を実装できる可能性が高いため、他のプロトコルは必要ありません。
于 2011-08-16T23:03:56.953 に答える
7
私は同じ問題を見ています。実際、RESTは迅速かつ簡単で、軽量の呼び出しと応答に適し、デバッグに最適であるように思われます（URLをブラウザーに送り込んで応答を確認するよりも優れている可能性があります）。
ただし、RESTが機能しなくなっているように見えるのは、RESTが標準ではないという事実に関係しています（ただし、RESTは標準で構成されています）。ほとんどのプログラミングライブラリには、WSDLを検査して、SOAPベースのサービスを利用するために必要なクライアントコードを自動的に生成する方法があります。これまでのところ、RESTベースのWebサービスを利用することは、可能な呼び出しに一致するインターフェイスを作成するためのよりアドホックなアプローチのようです。手動でhttpリクエストを作成してから、レスポンスを解析します。これ自体が危険な場合があります。
SOAPの利点は、WSDLが発行されると、ビジネスがロジックを構築できることです。これにより、インターフェイスを変更するとwsdlが変更されます。操縦の余地はありません。そのWSDLに対してすべてのリクエストを検証できます。ただし、WSDLはRESTサービスを適切に記述していないため、通信用のインターフェースについて合意する方法は定義されていません。
ビジネスの観点からは、これはコミュニケーションを解釈と変更に開放しているように見えますが、これは悪い考えのようです。
このスレッドの一番上の「回答」は、SOAPがSimple Object-Oriented Access Protocolの略であると言っているようですが、wikiを見ると、Oはオブジェクト指向ではなくオブジェクトを意味します。それらは異なるものです。
私はこの投稿が非常に古いことを知っていますが、私自身の発見で答えるべきだと思いました。
于 2011-06-17T17:16:17.030 に答える
6
いい質問ですね... 私はあなたを迷わせたくないので、あなたと同じように他の人の答えを受け入れます。私にとっては、実際にはオーバーヘッドのコストと API の使用法にかかっています。私はクライアント ソフトウェアを作成するときに Web サービスを使用することを好みますが、SOAP の重さは好きではありません。RESTは軽量だと思いますが、クライアントの観点からRESTで作業することはあまり好きではありません。
他の人がどう思うか興味があります。
于 2008-09-16T20:29:16.243 に答える
6
このポッドキャストを聞いて調べてください。聞かずに答えを知りたい場合は、OK、REST です。しかし、私は本当に聞くことをお勧めします。
于 2008-12-20T19:58:42.600 に答える
4
SOAPは、Web サービスに対するサービス指向のアプローチを体現しています。つまり、メソッド (または動詞) がサービスと対話する主要な方法です。RESTは、オブジェクト (または名詞) が中心となるリソース指向のアプローチを採用しています。
于 2013-01-07T07:00:42.700 に答える
4
「PHP-universe」の意味では、高度な SOAP に対する PHP のサポートは非常に手間がかかります。基本的なニーズを超えるとすぐにhttp://wso2.com/products/web-services-framework/php/のようなものを使用することになります.WS-SecurityまたはWS-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 サポートよりも確実に優れています。
SOA、WOA、ROA にさらにいくつかの BUZZ 単語を追加します
http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/
http://www.scribd.com/doc/15657444/REST-ホワイトペーパー
ところで、私は特に WS-Security 仕様の SOAP が大好きです。これは 1 つの優れた仕様であり、エンタープライズ JSON の適応を考えている人が、フィールド レベルの暗号化など、JSON に似たものを明確に用意する必要がある場合.
于 2013-02-26T17:03:49.263 に答える
3
簡単なポイント - 伝送プロトコルとオーケストレーション。
私は、速度、信頼性、およびセキュリティ上の理由から、組織化されたマシン ツー マシン サービス (ESB) や外部サービスに対して SOAP over TCP を使用しています。サービス定義を変更すると、オーケストレーションで WSDL の変更からエラーが発生し、すぐに明らかになり、再構築/デプロイできるようになります。
REST で同じことができるかどうかはわかりません - 修正されるかコースになるのを待っています! REST を使用して、サービス定義を変更します。400 (またはその他) が返されるまで、それについては何もわかりません。
于 2013-11-12T11:55:51.023 に答える
2
異なるシステムや言語間の相互運用性を探しているなら、私は間違いなくRESTを選びます。たとえば、.NETとJavaの間でSOAPを機能させるために多くの問題が発生しました。
于 2008-09-16T20:34:18.620 に答える
2
どちらが速いかを見つけるためのベンチマークを作成します! 私はこの結果を見る：
1000 リクエストの場合:
- REST に 3 秒かかりました
- SOAP は 7 秒かかりました
10,000 リクエストの場合:
- REST にかかった時間は 33 秒
- SOAP は 69 秒かかりました
1,000,000 リクエストの場合:
- REST にかかった時間は 62 秒
- SOAP は 114 秒かかりました
于 2016-01-23T11:53:30.167 に答える
0
古い質問ですが、今日でも関連しています....エンタープライズスペースの非常に多くの開発者がまだそれを使用しているためです。
私の仕事には、IoT (モノのインターネット) ソリューションの設計と開発が含まれます。これには、クラウドと通信する小さな組み込みデバイス用のコードの開発が含まれます。
REST が現在広く受け入れられており、有用であり、Web のデファクト スタンダードであることは明らかです。Microsoft でさえ、Azure 全体に REST サポートが含まれています。SOAP に頼る必要がある場合、必要なことを実行できませんでした。小さな組み込みデバイスには大きすぎてかさばり、煩わしいからです。
REST はシンプルでクリーンで小さいです。小型組み込み機器に最適です。WSDL を送ってくる Web 開発者と一緒に仕事をしていると、いつも悲鳴を上げます。なぜこれが機能しないのか、なぜRESTを学ばなければならないのかについて、教育キャンペーンを開始する必要があるからです。
于 2015-03-12T02:46:49.400 に答える