7

PHP アプリケーション用の Web サービスを実装しており、標準の Web サービスと RESTful Web サービスの両方が提供するものを理解しようとしています。私の意図は、ラッパー コードを記述して Web サービスの詳細を抽象化し、開発者が単に「リモート オブジェクトをインスタンス化」して使用できるようにすることです。これが私の考えです、おそらくあなたの何人かはあなたの経験を追加してこれを拡張することができます：

RESTful Web サービス

基本的には「オンデマンドの XML フィード」です。たとえば、クライアント アプリケーションのラッパー コードを記述して、次の方法でサーバー アプリケーションにクエリを実行できます。

$users = Users::getUsers("state = 'CO'");
  • これにより、リモート URL から XML フィードが取得されます。
  • $users は、完全な User オブジェクトのコレクションにすることができます。
  • XMLのまま、または
  • 配列などに変換されます。
  • クエリ スクリプト ("state = 'CO'") は、サーバー側で SQL に変換されます。

  • 通常、RESTful Web サービスはクライアントから見ると読み取り専用ですが、POST または GET を使用してサーバーに変更を加えるコードを作成することもできます。たとえば、セキュリティのために暗号化されたトークンを渡すなどです。

    $users = ユーザー::addUser($encryptedTrustToken, 'jim',$encryptedPassword, 'James', 'Taylor');

これにより、サーバー アプリケーションに新しいユーザーが作成されます。

標準 Web サービス

結局、標準 Web サービスは基本的に同じことを行います。利点の 1 つは、クライアントが WSDL を介して詳細を検出できることです。しかし、それ以外に、開発者がオブジェクトをリモートでインスタンス化、編集、および保存できるようにするラッパー コードを書きたい場合は、ラッパー コードを実装する必要があります。SOAPは私のためにそれをしません。これを行うことができます:

$soap = new nusoap_client('http://localhost/test/webservice_user.php?wsdl', true);
$user = $soap->getProxy(); 
$lastName = $user->lastName();

しかし、編集して保存したい場合：

$user->setLastName('Jones');
$user->save();

次に、たとえばサーバー側ですべての状態を処理する必要があります.SOAPは、クライアントごとにサーバー側でそのオブジェクトを保持していないようです。

おそらく、私が使用している PHP SOAP 実装 (nusoap) には制限があります。おそらく、Java と .NET の実装はさらに多くのことを行います。

これらの雲の一部を解消するために、フィードバックをお楽しみください。

4

5 に答える 5

8

それらは異なるモデルです... RESTはデータ中心ですが、SOAPは操作中心です。つまり、SOAP では、"SubmitOrder" などの個別の操作を行う傾向があります。しかし、REST を使用すると、通常、データのクエリ方法についてより流動的になります。

また、SOAP はさらに複雑になる傾向があります (必要な場合もあります)。REST は POX などに戻り、YAGNIに戻ります。

.NET に関して言えば、「wsdl.exe」のようなツールは、SOAP サービス (ま​​たは WCF サービスの場合は「svcutil.exe」) を表す完全なクライアント側プロキシ ライブラリを提供します。

var someResult = proxy.SubmitOrder(...);

.NET を使用した REST の場合、ADO.NET Data Services が最も明白なプレーヤーであると思います。ここで、ツール (datasvcutil.exe) は、LINQ をサポートする完全なクライアント側のデータ コンテキストを提供します。LINQ は、複雑なクエリを形成する .NET の比較的新しい方法です。したがって、次のようになります (強力/静的型チェックとインテリセンスを使用):

var qry = from user in ctx.Users
          where user.State == 'CO'
          select user;

(これは、ADO.NET Data Services の適切な REST 構文との間で変換されます)

于 2008-11-17T17:01:02.100 に答える
2

私はマーク・グラヴェルが言ったことをエコーし​​ています。人々がRESTについて私に尋ねるとき（そして彼らは通常SOAPとSOAについての考えを持っています）、それはリソース/データ指向であり、それは異なるパラダイムであり、したがって異なる設計上の懸念があるため、REST=ROAと言います。

あなたの場合、私があなたを正しく読んでいるなら、ラッパーコードを書くことを避け、オブジェクトとその属性をリモートで保存できる（そしてそれらを開発者から完全に隠すことができる）ソリューションが必要です。私は本当により良い解決策を提案することはできません..うーん、これらのいずれかがあなたの要件を満たすために近づいたかどうか私に知らせてください：

  1. EJB3 / JPA
  2. CouchDB（REST / JSON）

私があなたの質問を間違って解釈した場合も私に知らせてください。

XML-RPCとSOAPを比較すると、後者の方がデータ型の処理が向上します。前者の場合、より単純なデータ型を処理しますが、それらをドメインオブジェクトに変換するには、レイヤーまたはアダプターを作成する必要があります。

yc

于 2008-11-18T03:44:48.883 に答える
1

SOAP は、標準化グループによって承認された、合意された XML スキーマのセットにすぎません。その強みは、相互運用性のために設計されており、多くのエンタープライズ クラスの機能をサポートしていることです。どのプラットフォームの SOAP も、探している操作を提供しません。これらの機能を取得するには、サービス コントラクトを設計および実装する必要があります。

Soap も REST も特に適していないリモート オブジェクトが必要なようです。XML-RPCを見たほうがいいかもしれません。

于 2008-11-17T17:19:42.377 に答える
0

主な違いは基本的にツールです。

ハイエンドの SOAP スタックの多くは、開発者から、DTO/ドキュメントと RPC のみを使用して作業している場所まで、膨大な量の SOAP インフラストラクチャを覆い隠しています。

HTTP 経由の REST では、開発者の負担が大きくなります (フォーマット [XML、JSON、HTTP POST] のネゴシエーション、結果の解析 [DOM、マップ、DTO マーシャリングなど])。

明らかに、ロジックのレイヤーを記述して、この詳細を簡単に処理できます。そして、これを簡単にするためにいくつかの REST フレームワークが登場しましたが、現時点では、そのようなサービスを使用または消費したい場合は、TODO リストにまだタスクがあります。

于 2008-11-17T17:03:01.630 に答える
0

私のフィードバックは、リモート状態が必要な場合は、Web サービスについて話しているわけではないということです。リモート状態を扱う現代のモデルについては知りません。遠隔地が必要な場合は、自分で（従うべき宗教なしで）独立していると思います。ここからそこへxmlを投げるだけで、理論は気にしないでください。

リモート状態が悪であることを付け加える必要があります。できれば避けてください。

于 2008-11-17T17:04:52.763 に答える