2009-05-06 12 views
4

RESTの原則を理解しているので、URLはユーザーや製品のような単一のリソースを表す必要があります。ランダムなリソースや動的に生成されるリソースはどのように扱いますか?RESTfulなコンテキストで動的リソースをどのように処理しますか?

ランダムな整数を返すapi.example.com/integerというリソースを作成するとします。私はまだ整数を取得するためにGETを使用しますか?この文脈でPOST、PUT、DELETEの意味は何ですか?

動作を表すURLはどうですか? 2つの数値の合計を返すapi.example.com/addというリソースを作成したとします。このリソースを使用する場合は、GETまたはPOSTを使用して追加する番号を送信しますか?

答えて

7

すべてのリソースがすべての動詞をサポートする必要はありません。 OPTIONS動詞は、どの動詞がサポートされているかを調べるためのものです。

私は、次のどちらかがどちらかが有効である可能性がかなり自明

GET http://api.example.org/RandomInteger 

POST http://api.example.org/RandomNumberMachine 

あると言うでしょう。 GETリクエストがキャッシュされるように注意してください。もしそうなら、あなたはランダムな結果を得ることはありません。

RESTの背後にある主な原則の1つは、URLが動詞ではなく名詞を表すことをモデル化することです。だからhttp://api.example.com/addは理想的なURLではありません。

あなたは追加するための番号が含まれているいくつかの標準的なフォーマットのエンティティボディで

GET http://api.example.org/Summation?Values=2,4 

または

POST http://api.example.org/AddingMachine 

を行うことができます。

"Add"で終わるURLと "summation"で終わるURLを区別するのはかなり賢明なようです。しかし、これは非常に単純な例であり、RESTの制約は、分散システムにとって望ましい特性を持つ設計を導くためのものです。

何年も前の人が

apple.bite() 

bite(apple) 

との違いを主張するだろう有意ではなかったです。私は最近、あまりにも多くの人がこの区別を却下するとは思わない。

+0

"RESTの背後にある主な原則の1つは、あなたのURLが動詞ではなく名詞を表すことをモデル化することです。これは誤りです.RESTはURI命名については何も言いません。私はあなたが権威ある情報源に相談していないと思う。 – aehlke

+0

私は言い換えるとどうですか? http動詞を正確に使用するための手引きの最も簡単な方法の1つは、名詞と動詞が含まれていないUri'sを使用することです。プロシージャ言語のように論理的にuriの名前を付ける必要はありません。プロシージャ名に論理名を付ける必要はありません。しかし、あなたのuriを名詞として読むことができれば、わかりやすいです。GET PUT DELETE

+0

GETの部分は、サーバーとクライアントの間にキャッシュが存在しないことに依存します。あなたは冪等元のリソースに対してGETを行うべきです。乱数は明らかにそうではありませんので、GETは有効な答えではないと思います。それはうまくいくかもしれませんが、正しく "RESTful"ではありません。 – occulus

3

私はGETが乱数に適していると思います。そのリソースに対して単にPOST、PUT、またはDELETEを許可しないでください。合計

、なぜだけでなく:

getSum加数= 3,5,8

REPONSEは16

POST is for whenあなたは「オリジンサーバはで囲まれたエンティティを受け入れたいのですか? Request-LineのRequest-URIによって識別されるリソースの新しい下位要素としての要求

この場合、サーバーが加数を永久に受け入れる/覚えておく必要はないため、POSTは適切ではありません。

+0

これは、「データ処理プロセスにフォームを送信した結果などのデータブロックを提供する」ためのものです。このように、それは他の方法に適合しないもののためのすべてのものになります。 POSTは作成を意味するだけではありません。 –

+0

私はいくつかの加数をデータブロックとは考えません。 –

+0

GETメソッドは、安全で冪等のリソースの表現を取得するためのメソッドですが、乱数は動的です。これにGETを使用すると、確かに多くの問題につながる可能性があります。 POSTはGETよりはるかに適切です。 – occulus

3

リソースはリソースです。それは、生涯にわたり、変更、変異、逆さま、または何かを反転することができます。最初のケースのリソースは乱数ではなく、乱数ジェネレーターです。

Darrel氏によると、すべてのリソースがすべてのHTTPのメソッドをRESTfulにすることは必須ではありません。ヘック、私はGET(コレクションをフェッチすること)とPOST(コレクションに新しいリソースを追加するため、そしておそらく他のコレクションを同時に追加するためのさまざまなコレクションリソースを持つRESTfulシステムを用意しています。他のリソースはGET、PUT(更新用)、およびDELETEをサポートしています。 RESTfulインターフェイスの重要な点は、普遍的に適用可能なことです。 - プロトコルのメソッドは、多くの異なる種類のリソースに一般的な方法で適用されます。普遍的にはが使用されます。リソースは完全なインタフェースを実装する必要があります。

HTTPsメソッドには、セマンティクスが定義されています。それらのセマンティクスがあなたのリソースに適切に適用される場合は、それらを実装します。そうでない場合は、しないでください。

HTTPのコンテキストでは、GETは、合計の例のような何かを行うための完全に良い方法です。任意の検索エンジンを見てください。彼らはすべてGETを使用して検索を行いますが、これは完全にRESTfulです。ブラウザーには、検索を表すリソースのURLを構成する方法に関する帯域外情報はありませんが、フォームを含むページをダウンロードすることで、その方法の説明がダウンロードされます。これはHATEOASと自己記述の本質の一部です。あなたはより多くのことを学ぶにつれて遭遇することになります。

-2

RPCを使用してください。 RESTはあらゆる目的に適していません。

+0

加算番号はRESTではなくRPCに適しています。 – aehlke

関連する問題