私はRESTfulデータストアを構築し、条件付きGETとPUTを活用しています。条件付きPUT中に、クライアントはリソースに前のGETからのEtagを含めることができ、現在の表現が一致しない場合、サーバーは412（前提条件失敗）のHTTPステータスコードを返します。これはAtomベースのサーバー/プロトコルであることに注意してください。
私の質問は、412ステータスを返すときに、リソースの新しい表現も含めることができますか、それともユーザーが新しいGETを発行する必要がありますか？HTTP仕様は、yesまたはnoを示していないようであり、Atom仕様も示していません（ただし、それらの例では、応答に空のエンティティ本体が示されています）。新しい表現を返さず、クライアントにそれを具体的に取得させるのはかなり無駄に思えます。考え？
条件付きGETとPUTは「条件付きリクエスト」として要約されますが、概念的には大きく異なります。条件付きGETはパフォーマンスの最適化であり、条件付きPUTは同時実行制御メカニズムです。それらを一緒に議論するのは難しいです。
条件付きGETに関する質問へ：GETを送信し、If-None-Matchヘッダーを含めると、サーバーはリソースが変更された場合は200 Okを送信し、変更されなかった場合（条件が失敗した場合）は304NotModifiedを送信します。412は、条件付きPUTでのみ使用されます。
更新：質問を少し読み間違えたようです。条件付きPUTが失敗した場合のローカルコピーの「更新」に関するポイント：キャッシュにはすでに最新バージョンがあり、refresh-GETはいくつかのキャッシュから提供される可能性があります。サーバーに412で現在のエンティティを返すようにすると、実際にはパフォーマンスが低下する可能性があります。
いいえ、技術的にはすべきではありません。エラー コードは通常、何か問題が発生したことを示します。コンテンツを返すことを妨げるものは何もありませんが (実際、404 のような一部のエラーでは、探しているものが見つかりませんでしたというきれいなページが返されます)、応答のポイントは他のコンテンツを返すことではありませんが、何が間違っていたのかを伝える何かを返します。技術的には、If-None-Match: etag を渡したので、そのデータを返すべきではありません (それがあなたが渡したものだと思いますか?)
別の注意として、追加の http 呼び出しを最適化する必要は本当にありますか?
これについて考えれば考えるほど、それは悪い考えだと確信するようになりました - 他のエラーでコンテンツを返すつもりですか? PUT セマンティクスは PUT です。GET には GET セマンティクスを使用する必要があります。
更新の競合後に追加のリクエストが発生したために発生した追加のリクエストの数が、パフォーマンスに懸念があるほど大きい場合は、リソースの粒度に問題がある可能性があることをお勧めします。
複数のユーザーが 1 日に何百万回も同じリソースを同時に編集することを本当に期待していますか? リソースを直接更新する代わりに、デルタ変更をリソースに保存する必要があるかもしれません。これらのリソースに対して本当に多くの競合がある場合、ユーザーは常に古いデータで作業することになるのではないでしょうか。
リソースに最終変更日と最終変更ユーザーが含まれていて、PUT のたびに GET を実行する必要があることが問題である場合、ルールをひねる必要があると確信できます。
ただし、追加のリクエストによるパフォーマンスへの影響は、クライアント開発者にとって明確にするために価値があると思います。