153

今日、REST に関する興味深いデモに参加しましたが、REST が SOAP ベースのサービス スタックよりも使いやすく、実装しやすい理由を 1 つも思いつきませんでした (提示もされませんでした)。

「現実世界」の誰もが SOAP ベースのサービスの代わりに REST を使用する理由は何ですか?

4

11 に答える 11

160

オーバーヘッドが少ない (すべての呼び出しをラップする SOAP エンベロープがない)

重複が少ない (HTTP は、SOAP エンベロープで表現する必要がある DELETE、PUT、GET などの操作を既に表現しています)。

より標準化された - HTTP 操作は十分に理解され、一貫して動作します。一部の SOAP 実装は扱いにくい場合があります。

人間が読みやすく、テストしやすい (ブラウザだけで SOAP をテストするのは難しい)。

XML を使用する必要はありません (SOAP の場合もそうする必要はありませんが、既にエンベロープの解析を行っているため、ほとんど意味がありません)。

ライブラリはSOAPを(一種の)簡単なものにしました。しかし、私が指摘したように、あなたはその下にある多くの冗長性を抽象化しています。はい、理論的には、SOAP は他のトランスポートを介して同様のことを行うレイヤーの上に乗ることを避けることができますが、実際には、これまでに行う SOAP 作業のほぼすべてが HTTP を介して行われます。

于 2008-09-18T06:18:19.737 に答える
36

RESTfulサービスは、 SOAPベースの (通常の) サービスよりもはるかに簡単に使用できます。その理由は、REST が通常の HTTP リクエストに基づいているためです。これにより、行われるリクエストのタイプ (GET = 取得、POST = 書き込み、DELETE = 削除など) から意図を推測できるようになり、完全にステートレスになります。一方で、リクエスト コンテキストを含むメッセージ エンベロープの概念がなくなるため、柔軟性に欠けると主張することもできます。

私の経験では、企業内のサービスには SOAP が好まれ、パブリック API として公開されるサービスには REST が好まれてきました。

.NET フレームワークの WCF などのツールを使用すると、サービスを REST または SOAP として実装するのは非常に簡単です。

関連する読み物:

于 2008-09-18T06:21:37.950 に答える
13

「Web サービス」と言うときは、SOAP と WS-* 標準セットを意味していると思います。(そうでなければ、REST サービスは「Web サービス」であると主張できます。)

標準的な議論は、REST サービスは Web の設計、つまり HTTP および関連するインフラストラクチャの設計により近いというものです。したがって、REST サービスを使用すると、既存の Web ツールや手法との互換性が高まります。

もちろん、詳細を掘り下げると、両方のアプローチがさまざまなシナリオで強みを持っていることがわかります。あなたが興味を持っているのはそれらの詳細ですか?

于 2008-09-18T06:16:45.887 に答える
10

オーバーヘッドは、優れたアーキテクチャほど重要ではありません。

RESTはプロトコルではなく、優れたスケーラブルな設計を促進するアーキテクチャです。RPCの自由度が高すぎると、設計が貧弱になる可能性があるため、これがよく選択されます。

もう1つの理由は、既存のテクノロジー(主にプロキシ)を活用できるため、HTTPを介したRESTfulプロトコルの予測可能なコストです。RPCの初期コストは非常に低いですが、負荷が増大すると大幅に増加する傾向があります。

于 2009-04-25T21:15:44.417 に答える
7

このトピックに関するRoy Fielding の最も優れた論文を読みました。彼は優れた主張をしており、彼がそれを書いたとき (2000 年) は間違いなく時代を先取りしていました

于 2008-09-18T06:23:38.617 に答える
7

REST は実装にとらわれず、はるかに透過的であるため、パブリック API、特に API をマーケティング ツールとして使用し、人々にデータを消費してもらいたい Flickr、Amazon、Digg などの大規模な Web サイトに最適です。彼らは、選択したスクリプト言語のバグのある SOAP ライブラリをデバッグしようとしている何千人もの初心者開発者を手放すことを望んでいません。

SOAP や WSDL と比較すると、ドロップイン ライブラリがあり、両端に知識豊富な人がいる内部アプリケーションに適しています。(そして、インターネット規模の負荷分散、HTTP キャッシングなどを気にする必要はないかもしれません。)その後、自己文書化された API を取得し、タイプを保持するなど、作業は一切必要ありません。

于 2008-09-18T06:43:37.413 に答える
6

Steve Vinoski のブログと彼の最新記事は、一読の価値があります。彼は元 CORBA の第一人者であり、ミチ・ヘニングと共著でおそらく最高の本、『Advanced CORBA® Programming with C++』を書いています。しかし、それ以来、彼はクライアント/サーバーのやり方の誤りに気づき、今では REST に誓っています。

于 2008-09-18T06:24:37.070 に答える
5

REST では、非変更操​​作 (通常は GET 動詞を使用) をキャッシュできます。つまり、クライアントによってキャッシュされたり、プロキシによってキャッシュされたりします。これは大きな勝利になる可能性があります!

于 2008-09-23T20:16:45.973 に答える
3

REST は基本的に、Web サービスを実装するための手段にすぎません。これは、ヒットしようとしている Web サービスを照会するために HTTP を正しく使用する方法にすぎません。

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

于 2008-09-18T06:16:29.583 に答える
0

超シンプルでスリムです。http 動詞の GET を介してブラウザで実行できます。一般的な http POST リクエストを手動で簡単に実行できるブラウザが見つからない

于 2008-09-18T06:38:38.970 に答える
0

ここに 1 つのデータ ポイントがあります。Amazon は API を REST と SOAP の両方の形式で提供しており、使用量の 85% は REST です。

REST は実装が簡単で、理解しやすく、パフォーマンスが高いです。

于 2009-07-04T05:53:22.773 に答える