8

PUT 呼び出しに関する RESTful な設計パターンについてもっと知りたいと思っています。具体的には、リソース ID を PUT 呼び出しの一部として変更することは、規範に違反していますか?

次のことを検討してください...

POST /api/event/  { ... } - returns the resource ID (eventid) of the new event in the body
GET  /api/event/eventid
PUT  /api/event/eventid   - returns the (possibly new) resource ID depending on request body
GET  /api/event/eventid   - fails if the original eventid was used in the URI

eventid が内部リソース (データベース レコードなど) を表す場合、GET および PUT のエンドポイントはリソースにすばやくアクセスできます。PUT によってサーバーが基になるリソースを移動する場合、ID は変更される可能性があります。

これを行うと、規範に違反しますか?

4

3 に答える 3

6

REST は厳密な仕様ではありませんが、理解しやすく操作しやすい Web サービスを構築するために従うことができる一連のガイドラインとベスト プラクティスです。したがって、PUT 中にリソース ID を変更することを妨げるものは何もありません。

そうは言っても、そうするのはIMOの悪い習慣です。REST の背後にある考え方の 1 つは、 URIを使用して各リソースを参照できるということです。あなたの場合、このURIはパスと（私が推測する）内部IDの連結です。この URI は、他の「システム」で使用され、参照として保存される可能性があります。PUT でリソースの ID を変更すると、URI が変更され、そのリソースへのすべての参照が壊れます (404)。

URI の一部である ID を変更する必要がある場合は、適切なプロパティを選択していない可能性があります。不変のものを検討してください (例: リソースにUUIDをタグ付けし、内部 DB ID ではなくそれを使用します)。

于 2012-11-07T03:08:28.840 に答える
1

あなたの質問に完全に対処していませんが、これは私を心配させます：

本文内の新しいイベントのリソースID（eventid）を返します

整数IDを返さないので、クライアントにこれからURLを作成させますか？適切なRESTアプリケーションは、IDではなくリソースにURLを与える必要があります。

あなたの質問に関しては-PUTは「この場所に新しいリソースを作成する」のようなものを意味します。リダイレクトとヘッダーで返信することも考えられますがLocation、それは少し奇妙なことです。さらに、PUTのセマンティクスでは、エンティティ全体をリクエストとともに送信する必要がありますが、これはおそらくこのシナリオでは必要ありません。たぶん、この状況でPOSTを使用する方が適切でしょうか？（例：POST on/api/event/1234

于 2012-06-18T21:15:45.753 に答える
1

大丈夫だと思います。PUT は依然として冪等です (呼び出しを繰り返しても他の変更は発生しません)。

ただ：古いIDが再利用されないようにし、APIが古いIDへの呼び出しに対して301コードを返すようにします（他のクライアントがリソースへのリンクを持っている場合）。

おそらく、ID を変更する最初の PUT は、新しいリソースの場所を指す 303 コードを返すはずですが、ここではわかりません。

于 2012-06-19T09:49:38.377 に答える