リソースがすでに存在する場合のPOSTのHTTP応答コード

クライアントがオブジェクトを保存できるサーバーを構築しています。これらのオブジェクトはクライアント側で完全に構築され、オブジェクトの存続期間全体にわたって永続的なオブジェクト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は「追加」操作を意図しているので、オブジェクトがすでにそこにある場合にどうすればよいかわかりません。リクエストを変更リクエストとして処理する必要がありますか、それともエラーコード（どちらか）を返す必要がありますか？

私の気持ちは409 Conflict最も適切ですが、もちろん自然界ではめったに見られません。

リソースの現在の状態との競合のため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。レスポンスボディには、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります（SHOULD）。理想的には、応答エンティティには、ユーザーまたはユーザーエージェントが問題を修正するのに十分な情報が含まれます。ただし、それは不可能である場合があり、必須ではありません。

競合は、PUTリクエストへの応答で発生する可能性が最も高いです。たとえば、バージョニングが使用されていて、PUTされているエンティティにリソースへの変更が含まれており、それが以前の（サードパーティ）リクエストによる変更と競合する場合、サーバーは409レスポンスを使用して、リクエストを完了できないことを示します。 。この場合、応答エンティティには、応答のContent-Typeで定義された形式で2つのバージョンの違いのリストが含まれている可能性があります。

RFC 7231によると、POSTの処理結果が既存のリソースの表現と同等である場合は、303 See Otherを使用できます。

個人的に私はWebDAV拡張を使い422 Unprocessable Entityます。

RFC 4918によると

422 Unprocessable Entityステータスコードは、サーバは、要求エンティティ（ひいてはのコンテンツタイプを理解する意味415 Unsupported Media Typeステータスコードが不適切である）、および要求エンティティの構文が（従って正しい400 Bad Requestステータスコードが不適切である）が、含まれる命令を処理できませんでした。

すべてはコンテキストに関するものであり、リクエストの重複の処理を担当するのは誰（サーバーまたはクライアント、あるいはその両方）

サーバーが複製をポイントするだけの場合は、4xxを見てください。

• 400 Bad Request-明らかなクライアント障害のため、サーバーがリクエストを処理しない場合
• 409競合-サーバーが要求を処理しないが、その理由はクライアントの障害ではない場合
• ...

以下のために暗黙の重複の取り扱い、2XXを見て：

• 200 OK
• 201作成されました
• ...

サーバーが何かを返すことが予想される場合は、3XXを見てください。

• 302見つかりました
• 303他を見る
• ...

サーバーが既存のリソースをポイントできる場合、リダイレクトを意味します。

上記では不十分な場合は、応答の本文にエラーメッセージを準備することをお勧めします。

ゲームの後期かもしれませんが、REST APIを作成しようとしたときにこのセマンティクスの問題に遭遇しました。

Wrikkenの答えを少し拡張するには、どちらか、409 Conflictまたは403 Forbidden状況に応じて使用できると思います。つまり、ユーザーが競合を解決してリクエストを完了するために何もできない場合は、403エラーを使用します（たとえば、DELETEリソースを明示的に削除するリクエスト）、または何かが実行される可能性がある場合は409を使用します。

10.4.4 403 Forbidden

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADではなく、サーバーがリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます。

今日では、誰かが「403」と言って、権限または認証の問題が頭に浮かびますが、仕様では、基本的にサーバーがクライアントにそれを実行しないことを伝えていることを再確認しないでください。ない

用としてPUT対POST... POSTユーザが手段を持たないか、リソースの識別子を作成するべきではないリソースの新しいインスタンスを作成するために使用されなければなりません。PUTリソースのIDがわかっている場合に使用されます。

9.6 PUT

...

POST要求とPUT要求の基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データ受け入れプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる個別のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストに含まれるエンティティを識別します。ユーザーエージェントは、意図するURIを認識しており、サーバーは他のリソースへのリクエストの適用を試みてはいけません。サーバーがリクエストを別のURIに適用したい場合は、

301（永久に移動）応答を送信する必要があります。次に、ユーザーエージェントは、リクエストをリダイレクトするかどうかについて独自の決定を行うことができます。

「302 Found」は私にとって論理的に聞こえます。また、RFC 2616には、GETおよびHEAD以外のリクエストでも応答できると記載されています（これには確かにPOSTが含まれます）。

ただし、RFCにより、訪問者がこの「見つかる」リソースを取得するためにこのURLにアクセスすることはできます。実際の「見つかった」URLに直接移動するには、「303 See Other」を使用する必要があります。これは理にかなっていますが、次のURLを取得するために別の呼び出しを強制します。良い面として、このGETはキャッシュ可能です。

「303 See Other」を使用すると思います。本文で見つかった「もの」で応答できるかどうかはわかりませんが、サーバーへの1回の往復を節約するためにそうしたいと思います。

更新： RFCを再度読んだ後でも、存在しない "4XX + 303 Found"コードが正しいはずです。ただし、「409 Conflict」は（@Wrikkenが指す）最良の既存の回答コードであり、おそらく既存のリソースを指すLocationヘッダーを含みます。

私はあなたがこれをするべきではないと思います。

ご存知のように、POSTはコレクションを変更するためのもので、新しいアイテムを作成するために使用されます。したがって、IDを送信する場合（これは良い考えではないと思います）、コレクションを変更する必要があります。つまり、アイテムを変更しますが、混乱を招きます。

IDなしでアイテムを追加するために使用します。これがベストプラクティスです。

（IDではなく）UNIQUE制約をキャプチャする場合は、PUTリクエストの場合と同様に、409を応答できます。しかし、IDではありません。

私は行くだろう422 Unprocessable Entity要求が無効であるが、問題は構文または認証していないときに使用されます、。

他の回答に対する反対意見として、4xxエラー以外のコードを使用することは、それがクライアントエラーではないことを意味します。4xxエラー以外のコードを使用してクライアントエラーを表すことは、まったく意味がありません。

409 Conflictここでそれが最も一般的な答えのようですが、仕様によると、これはリソースがすでに存在し、それに適用する新しいデータが現在の状態と互換性がないことを意味します。あなたが送信している場合POSTたとえば、すでに使用されているユーザー名を使用して、ターゲットリソース（作成しようとしているリソース）がまだポストされていないため、実際にはターゲットリソースと競合していません。保存されているリソースのバージョンと要求されたリソースのバージョンの間に矛盾がある場合、これは特にバージョン管理のエラーです。これは、クライアントが古いバージョンのリソースをキャッシュし、条件付きで有効ではなくなった誤ったバージョンに基づいてリクエストを送信する場合など、その目的に非常に役立ちます。「この場合、応答の表現には、変更履歴に基づいて差異をマージするのに役立つ情報が含まれている可能性があります。」そのユーザー名で別のユーザーを作成する要求は、バージョン管理とは関係なく、単に処理できません。

記録では、422は、すでに使用されている名前でリポジトリを作成しようとしたときにGitHubが使用するステータスコードでもあります。

RESTの場合、その特定のシステムの動作を決定する必要があるだけだと思います。その場合、「正しい」答えは、ここに示されている2つの答えのうちの1つだと思います。リクエストを停止して、クライアントがミスしてから続行する前に修正する必要があるかのように動作させる場合は、409を使用します。競合がそれほど重要ではなく、リクエストを続行したい場合は、リダイレクトして応答します。見つかったエンティティへのクライアント。とにかく、適切なREST APIはPOST後のそのリソースのGETエンドポイントにリダイレクト（または少なくともロケーションヘッダーを提供）する必要があるので、この動作により一貫したエクスペリエンスが得られます。

編集：IDを提供するので、PUTを検討する必要があることにも注意する価値があります。その場合の動作は単純です。「現在何があるか気にしないので、これをそこに置いてください。」つまり、何もない場合は作成されます。何かがある場合は置き換えられます。サーバーがそのIDを管理する場合は、POSTの方が適切だと思います。2つの概念を分けると、基本的には対処方法がわかります（つまり、PUTはべき等であるため、ペイロードが検証される限り常に機能し、POSTが常に作成されるため、IDの衝突がある場合、409はその競合を説明します） 。

もう1つの潜在的な治療法は、結局のところPATCHの使用です。PATCHは、内部状態を変更するものとして定義され、追加に限定されません。

PATCHは、既存のアイテムを更新できるようにすることで問題を解決します。参照：RFC 5789：PATCH

なぜ202は受け入れられないのですか？それはOKリクエスト（200秒）であり、クライアントエラー（400秒）はありませんでした。

10のステータスコードの定義：

「202 Accepted。リクエストは処理のために受け入れられましたが、処理は完了していません。」

...すでに存在するため、完了する必要はありませんでした。クライアントはそれがすでに存在していることを知りません、彼らは何も間違っていませんでした。

私は202をスローし、GET /{resource}/{id}が返すものと同様のコンテンツを返すことに頼っています。

重複するレコードの正しいコードをチェックしているときに、この質問に遭遇しました。

私の無知を許してください。しかし、なぜ「複数選択」または「あいまい」と明確に述べているコード「300」を誰もが無視しているのか理解できません。

私の意見では、これは非標準または独自の使用のための特定のシステムを構築するのに最適なコードでしょう。私も間違っている可能性があります！

https://tools.ietf.org/html/rfc7231#section-6.4.1

より可能性が高い 400 Bad Request

6.5.1。400不正な要求

400（Bad Request）ステータスコードは、クライアントエラーであると認識される何か（たとえば、不正な形式の要求構文、無効な要求メッセージのフレーミング、または不正な要求ルーティング）により、サーバーが要求を処理できない、または処理しないことを示します。

リクエストに重複する値（すでに存在する値）が含まれているため、クライアントエラーとして認識される可能性があります。次の試行の前に要求を変更する必要があります。
これらの事実を考慮することにより、HTTP STATUS 400 Bad Requestと結論付けることができます。

208- http://httpstatusdogs.com/208-already-reportedはどうですか？それはオプションですか？

私の意見では、繰り返しリソースのみが存在する場合、エラーは発生しません。結局のところ、クライアント側でもサーバー側でもエラーは発生しません。

あなたの場合、あなたは使うことができます 409 Conflict

HTTPs下のリストから別のステータスコードを確認する場合

1××情報

100 Continue
101 Switching Protocols
102 Processing

2××成功

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3××リダイレクト

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4××クライアントエラー

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5××サーバーエラー

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error