仕様へのリンクから:
どのエンティティ タグも一致しない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず (MUST NOT)、412 (Precondition Failed) 応答を返さなければなりません。この動作は、PUT などの更新メソッドが、クライアントが最後にリソースを取得してから変更されたリソースを変更するのを防ぎたい場合に最も役立ちます。
仕様では HTTP 412 が必要であり (実際には「MUST」を使用しています)、議論中のユース ケースを正確に説明していることは明らかであるため、HTTP 412 が適切な応答コードのように見えます。
とにかく412はかなり妥当です。リクエストは、条件付きで更新を行うことを示しています。412 は条件が失敗したことを示しているため、サービスはそれを行いません。特に、412 は条件付きリクエストの概念に適しているためです。409は、本質的に条件付きである場合もそうでない場合もある、特定の種類の拒否に付随しているように思われます. たとえば、内部競合のあるものを POST する無条件の要求に応答して、サービスが 409 を返すのを見ることができました。
ただし、仕様からも以下を参照してください。
10.4.10 409 コンフリクト
リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。
競合は、PUT 要求への応答で発生する可能性が最も高くなります。たとえば、バージョニングが使用されていて、PUT されているエンティティに、以前の (サードパーティの) 要求によって行われたものと競合するリソースへの変更が含まれていた場合、サーバーは 409 応答を使用して、要求を完了できないことを示す可能性があります。 . この場合、応答エンティティには、応答の Content-Type によって定義された形式で、2 つのバージョン間の相違点のリストが含まれている可能性があります。
いずれにせよ、仕様では条件付きリクエスト コンテキストで 412 が必要なようですが、バージョンの競合が 409 の主な原因であることを示唆しています。バージョンの競合が無条件の要求の一部として発生する場合、409 が使用される可能性があります。