シンプルなCRUD REST APIを設計するには

Question

私はシンプルなCRUD REST APIを設計しています。これは初めてのことですので、私のデザインが理にかなっているかどうかについてのフィードバックを得たいと思っていました。

私はGET、POST、DELETE、およびUPDATEのHTTPメソッドを利用しています。 APIはJSON形式でデータを消費し、フェッチします。レコードがデータベースに作成されるPOSTリクエストの後

GET (list): curl http://<domain>/myapp/rest/v1/colors 
POST: curl -XPOST http://<domain>/myapp/rest/v1/colors -d '{ 
     "name": "red", 
     "shade": "light" 
     }' 
GET (single item): curl http://<domain>/myapp/rest/v1/colors/2 
DELETE: curl -XDELETE http://<domain>/myapp/rest/v1/colors/2 
etc... 

質問

：サンプルURLは、このようになります。だから、POST要求が新しく作成されたレコードのIDを返しますか？ IDはUPDATE, DELETE and GET (single item)で使用できますか？

Answer 1

HTTP specificationがPOSTについては、以下を定義：

リソースがオリジンサーバ上に作成されている場合、応答は201である（作成）し、要求のステータスを記述し、参照したエンティティを含むべきです新しいリソースとLocationヘッダ（セクション14.30参照）に追加します。

だから、これは本質的意味：

• をあなたは201 Createdあなたは、必要に応じて含めることができ、新しく作成したリソース
• のURIを指し、Locationヘッダを返すべき
ステータスコードを返す必要がありますクライアントが別の GET要求を Locationヘッダーから取得された値に対して発行する必要がなくなるように、POST応答本体内のリソースの表現。

Answer 2

POSTは、単一項目の新しいURLへのリダイレクトを返します。

おそらく、URLのバージョン識別子を失いたくなるでしょう。

代わりにさまざまなバージョンを適切に処理する方法で、表現とクライアントを設計します。たとえば、クライアントは特定の形式に依存する必要はなく、実際に必要な属性のみに依存する必要があります。

あなたの説明には、HATEOASの原則がありません。つまり、クライアントはURLをハードコードするべきではありませんが、他のエンティティの表現の中でさらなるアクションのURLを見つけるべきです。 URLから返された結果のサンプルドキュメントを表示していないので、これをうまくやったかどうかはわかりません。

this presentationをチェックしてください。トピックを説明し、Spring Libraryの実装に役立つSpringライブラリについても説明します。