REST API upsertエンドポイントとエンドポイントの作成と更新

Question

残りのうちで、ユーザーの作成/更新/削除を扱うREST APIを作成しています。

作成/更新ユーザーのエンドポイントを作成するベストプラクティスは何ですか？

1. ユーザーは、POST要求を作成および更新（= upsert）する両方の1つのエンドポイントを扱います。
2. 2つの異なるエンドポイント - ユーザー作成のPOST要求を処理するものと、更新ユーザーのPATCH要求を処理するもの。

Answer 1

ここで間違った前提がたくさんあります。 RESTでは、エンドポイントは「アクション」ではなく「物」を表します。

このことはユーザーだと言います。

http://example.org/users/roy 

ここから、すべての動作が自然になります。ユーザーを削除したいですか？

DELETE /users/roy 

更新しますか？

PUT /users/roy 

検索しますか？

GET /users/roy 

PUTは一般にPATCHよりもRESTfulであると考えられます。厳密にRESTを行っている場合は、PUTを実装することをお勧めします。 PUTとPATCHの違いと利点は、質問のために少し話題があると思います。

もう1つのアクションが残っています...新しいユーザーを作成するにはどうすればよいですか？さて、以下のようにベストプラクティスをまとめます：

クライアントがURIを判断できるようにするには、おそらくPUTを使用するべきです。

PUT /users/roy - Should respond with a 201. 

あなたが本当に古いものを上書きし、新しいユーザーを作成していないことを確認したい場合は、クライアントは、リソースがすでに存在する場合は、要求を拒絶するようにサーバを強制的にIf-None-Match: *ヘッダーを使用させることができます。

私は上記がベストプラクティスだと言いますが、それは最も一般的ではありません。一般的に休憩サービスは、いくつかのリレーショナルデータベースによってサポートされています。自然キーの代わりに、URIには整数がよく使われます。

これはあなたのURLパターンが

/users/1234 

のように見えるそれはまた、クライアントが新しいリソースを作成するときにURIが何であるかを知ることができないことを意味していることを意味します。これに対する典型的な回避策は、作成するためのPUTを使用していますが、コレクションのリソースのいくつかの種類を使用して、新しいユーザーを作成するためにPOSTを使用しないことです。

POST /users/ 

良いAPIは、おそらくへのURIを持つLocationヘッダを返します。新しく作成されたリソース。良いクライアントは、安全ではないメソッドの後にLocationヘッダーを受け取るたびに、そのuriのキャッシュをクリアする必要があることを知っています。