データベースに新しいレコードを作成/挿入するPOSTエンドポイントがあります。POSTが複数回呼び出されたときに返されるHTTPステータスは？
/payment/cardsは、支払いカードをDBに追加/保存し、200 OKのときに追加カード情報を返信します。さて、同じエンドポイントを再度呼び出すと、DB内の既存の支払いカードが更新されます。
私は支払いカードが既に存在するので、私たちがそれを更新しないように論理チェックを追加しています。
このシナリオで返されるHTTPステータスは何ですか？
新しいレスポンスが作成された場合はPOSTレスポンスで201を使用し、それ以外の場合は200または409を使用します。ただし、409コンフリクトが最も適切ですが、野生ではほとんど見られません。
リソースの現在の状態との競合が原因で要求を完了できませんでした。このコードは、ユーザーが競合を解決して要求を再送信できると予想される状況でのみ許可されます。応答本体は、ユーザが競合の原因を認識するのに十分な情報を含むべきである（SHOULD）。理想的には、レスポンスエンティティには、ユーザーまたはユーザーエージェントが問題を解決するのに十分な情報が含まれます。しかし、それは可能ではなく、必要ではないかもしれません。
競合は、PUT要求に応答して発生する可能性が最も高いです。たとえば、バージョニングが使用されていて、PUTに含まれるエンティティが、以前の（サードパーティの）要求と競合するリソースに変更された場合、サーバは409の応答を使用して要求を完了できないことを示します。この場合、レスポンスエンティティは、レスポンスContent-Typeで定義された形式で、2つのバージョン間の違いのリストを含む可能性が高くなります。
ええ、私は409と考えました.422はより適切ですか？任意の考えをしてください。422 UNPROCESSABLE ENTITY サーバーはリクエストエンティティのコンテンツタイプを理解しています（したがって、415サポートされていないメディアタイプステータスコードは不適切です）。リクエストエンティティの構文は正しいです（したがって、400 Bad Requestステータスコードは不適切な）が含まれている指示を処理することができませんでした。 たとえば、このエラー条件は、XML要求本文に整形式（つまり、構文上正しい）が、意味的に誤りのあるXML命令が含まれている場合に発生する可能性があります。 – deejo
間違いなく、409、または単に403を示唆しています。 – Evert