1

私は最近、SOAP ベースの Web サービスと RESTful Web サービスについて説明した Web サービスの本を読みました。どちらのパラメーターも (開発者の観点からも) 似ているため、どちらのパラメーターを選択する必要があるかわかりません。ここに私のポイントがあります

SOAP Web サービスでは、Web サービスから生成された WSDL ファイルを使用し、それに基づいてクライアント側のスタブを作成します。

私の理解では、内部的にスタブも HTTP プロトコルを使用してリモート Java Web サービスと通信します。右？

ここでは、HTTP リクエスト/レスポンス ボディ内に SOAP メッセージ (XML メッセージ) があります。したがって、REST ベースの Web サービスでは、HTTP 要求自体がメッセージとして動作している間にドリルダウンするレイヤーがもう 1 つあります。ここでは、WSDL の代わりに WADL を使用しています。ここでも、WADL に基づいてスタブを作成できます。したがって、消費者がプロデューサーに接続する技術的な違いと、リクエスト/レスポンスがどのように処理されるかを除いて、すべてのものは多かれ少なかれ同じように見えます.開発者の作業量はほぼ同じです）。

私の理解は正しいですか？

はい、おそらく舞台裏で、おそらくSOAPはREST Webサービスよりも複雑です.SOAPでは、メッセージ内にメッセージがあります（SOAPメッセージはHTTPリクエスト内に埋め込まれています）が、RESTベースのサービスでは、HTTPリクエスト自体がメッセージとして機能します.

4

3 に答える 3

3

SOAP と REST は、同じ一連の問題を解決することを目的としています。つまり、異種アプリケーション間の相互作用を可能な限り簡単な方法で促進します。REST と SOAP のどちらを選択するかは、開発作業の量だけに依存するものではありません。次の要因のいくつかも考慮する必要があります。

  1. アプリケーション間で交換される単純なオブジェクト (名前と値のペアなど) または非常に複雑なスキーマ (または一部のバイナリ データ)のデータの種類。
  2. サービスの消費者。たとえば、 RIAを開発している場合は、REST の方が適しています。
  3. セキュリティ要件。SOAP は標準主導であるため、セキュリティ面の非常に細かいレベルの調整を提供します。SOAP xml メッセージの個々の要素をある程度エンコードすることができます。これらのタイプのことは、REST では不可能です (少なくとも今のところ)。
  4. 現在、JSONのような表記法は軽量のデータ交換で非常に人気があり、多くの REST サービス フレームワークはこれを非常に簡単にすぐに利用できます。
  5. 技術的には、REST Web サービスを作成するためにフレームワークなどは必要ありません。最近WADLなどが標準化の要素を持ち込むために出てきたのは理解していますが、RESTはWADLが来る前から存在していました。REST は新しいものではなく、Web が機能する方法です。REST フレームワークを使用すると、非常に簡単になります。

SOAP は標準によって推進されているため、標準を使用する際には、より多くの制約を順守する必要があります。したがって、ユースケースが単純な場合 (これは非常に主観的です)、REST を使用してください。

于 2013-07-16T07:26:05.443 に答える