25

ある種の楽観的ロックを実装し、ETag を使用して最新のリソース状態を示したいとします。これは、クライアントが更新のIf-Match際にヘッダーを使用することを意味します。PUT

HTTP 仕様によると412 Precondition failed、ヘッダーに指定された ETag がIf-Matchリソースの現在の状態と一致しない場合、サーバーは返さなければなりません。

ただし、409 Conflict特に応答に何を含めるかのガイドラインを提供するため、意味的に表現したいものに近いようです。

ヘッダー409で提供された ETag との一致に失敗した場合に返すのは、ひどく間違っていますか?If-Match

4

1 に答える 1

38

仕様へのリンクから:

どのエンティティ タグも一致しない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず (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 が使用される可能性があります。

于 2013-10-01T20:03:26.313 に答える