私は、クライアントがオブジェクトを保存できるサーバーを構築しています。これらのオブジェクトは、オブジェクトの存続期間中永続的なオブジェクト ID を備え、クライアント側で完全に構築されます。
クライアントが PUT を使用してオブジェクトを作成または変更できるように API を定義しました。
PUT /objects/{id} HTTP/1.1
...
{json representation of the object}
{id} はオブジェクト ID なので、Request-URI の一部になります。
現在、クライアントが POST を使用してオブジェクトを作成できるようにすることも検討しています。
POST /objects/ HTTP/1.1
...
{json representation of the object, including ID}
POST は「追加」操作を意味するため、オブジェクトがすでに存在する場合に何をすべきかわかりません。リクエストを変更リクエストとして扱う必要がありますか、それとも何らかのエラー コードを返す必要がありますか (which)?
ベストアンサー1
私の感覚ではこれが409 Conflict最も適切ですが、もちろん野生ではあまり見られません。
リソースの現在の状態との競合のため、要求を完了できませんでした。このコードは、ユーザーが競合を解決して要求を再送信できる可能性がある場合にのみ許可されます。応答本体には、ユーザーが競合の原因を認識するのに十分な情報が含まれている必要があります。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を修正するのに十分な情報が含まれていますが、これは不可能な場合があり、必須ではありません。
競合は、PUT リクエストへの応答で発生する可能性が最も高くなります。たとえば、バージョン管理が使用されていて、PUT されるエンティティに、以前の (サードパーティの) リクエストによって行われた変更と競合するリソースの変更が含まれている場合、サーバーは 409 応答を使用して、リクエストを完了できないことを示す可能性があります。この場合、応答エンティティには、応答の Content-Type によって定義された形式で、2 つのバージョン間の相違点のリストが含まれる可能性があります。