11

RPCであるHTTPWebサービスがあります。これらは、取得または作成されたオブジェクトを表すXMLを返します。サービスを「再構築」することの利点(もしあれば)を知りたいです。

私が見ていることの1つは、すべてのリソースの表現は必要なく、すべてのリソースですべての操作(G​​ET、PUT、POST、DELETE)をサポートする必要もないということです。基本的に私の質問はこれです。

RPC over HTTPの代わりにRESTfulサービスを使用する必要があること、およびそれらのRESTfulサービスはどうあるべきかを私に納得させてください。

4

3 に答える 3

14

1つは、セマンティクスがすべてです。URIはURI(Uniform Resource Indicator)です。HTTPは、リソースをGET、POST、PUT、およびDELETEするためのメソッドを提供します。HTTPヘッダーは、情報を受信または送信する形式を指定します。これはすべて、HTTPプロトコルを介してすぐに利用できます。

したがって、HTML出力に使用するのと同じURLを再利用して、HTTPが使用されることを意図した方法でXML、JSONを取得できます。

XML-RPCSOAPは、XSDまたはWSDLファイルによって記述されたメソッドの呼び出しに基づいていますが、RESTはリソースの取得/変更に基づいています。違いは微妙ですが明らかです。URLはリソースのみを記述し、SOAPやXML-RPCの場合のようにアクションは記述しません。

RESTの利点は、HTTP動詞を利用して、create / new / addなどの名前が付けられたメソッド呼び出しに想定されるリソースを変更できることです。さまざまな種類のエラー応答の代わりに意味のあるHTTPステータスコードを使用し、さまざまなものを指定できます。標準的な方法で同じリソースのフォーマット。

また、RESTfulリソースのすべての動詞を受け入れる必要はありません。たとえば、読み取り専用リソースが必要な場合Method Not Allowedは、GETではない動詞の405ステータスコードを返すだけです。

RPC呼び出しをRESTにやり直す必要がありますか?いいえ、そうは思いません。メリットは開発時間を上回りません。新しいWebサービスをセットアップするときにRESTを学ぶ必要がありますか?はい、私は個人的にそう思います。RESTリソースを消費することは、はるかに自然に感じられ、はるかに急速に成長する可能性があります。

編集

RESTがXML-RPC/SOAPに勝ると思う理由は、Webサイトを開発するときに、HTMLへの出力に必要なすべてのデータを既に集約しているときに、POST本文の検証コードも作成するためです。トランスポートマークアップが変更されたという理由だけで、なぜ別のプロトコルに変更する必要があるのですか?

このように、新しいWebサイト(言語に依存しない)を設計するときに、URIをリソースと考える場合は、基本的にURIをメソッド呼び出しとして使用し、メソッド呼び出しの前にHTTP動詞を付けます。

つまり、HTTPヘッダーを持つ/ products / 12のGETは、Accept: application/json;基本的に(架空の)に変換されgetProducts(12,MimeType.Json)ます。

この「メソッド」は、いくつかのことを行う必要があります

  1. MIMEタイプとしてJSONをサポートしているかどうかを確認してください。(リクエストの検証)
  2. リクエストデータを検証する
  3. 製品12の集合体データ。
  4. JSONにフォーマットして返します。

今後4年間に何らかの理由で、YAMLが次の大流行になり、消費者の1人がそのように話したい場合、このMIMEタイプは通常のWebサービスよりもはるかに簡単にプラグインされます。

これで、製品12は、HTML MIMEタイプを受け入れて、その製品を表示する可能性が最も高いリソースですが、/product/12/reviews/14/対応するHTMLが必要ないようなURIの場合は、消費者がそのURLに投稿できるようにするだけです。自分のレビューをupdate(PUT)/ delete(DELETE)します。

URIを厳密にリソースとして考えると、Webページの場所だけでなく、これらのリソースをサーバー側のメソッド呼び出しへのHTTPリクエストと組み合わせると、クリーンな(SEO対応の)URLと(さらに重要なのは?)発達。

URIのメソッド呼び出しへのマッピングを自動的に行う任意の言語のフレームワークがあると確信しています。普段は自分で展開しているのでお勧めできません。

ASP.NET MVCも同じ原理で動作しますが、私の意見では、RESTfulURIを生成しません。ASP.NET MVCは、デフォルトでURIの動詞部分を作成しますが、ASP.NET MVCがこれ(またはそれに関すること)を強制することは決してないことに注意してください。

少なくともフレームワークを選択する場合は、次のようにする必要があります。

  1. URIをサーバー上のメソッドにバインドする
  2. Object to JSON/XMLなどのシリアル化をサポートします。言語にもよりますが、これを自分で書かなければならないのは苦痛ですが、それほど難しいことではありません。
  3. HTTPヘッダーを手動で解析せずに、要求されたものを判別するのに役立つ、ある種のタイプセーフな要求ヘルパーを公開します。
于 2009-05-11T16:23:11.820 に答える
3

URLから動詞を取り出してみてください。

于 2009-05-13T19:53:42.367 に答える
0

クエリ文字列は、階層的な非クエリ方式でリソースにアクセスするために使用しないでください。キャッシュ時にクエリ文字列は通常無視されますが、これは危険で低速です。

于 2009-07-20T22:10:08.610 に答える