次のユースケースを想像してみてください。
情報を取得するためにAJAXリクエストを使用し、次のItemURLを使用します：http：// domain / items / show / 1
私のデータベースでは、すべてのアイテムにmodified_at、このアイテムが以前に変更された瞬間を保存する場所というフィールドがあります。
サーバー側で毎回このリクエストを処理する必要がある場合、サーバーHTTPヘッダーは、どのようLast-Modifiedにして読み込みを最小限に抑え、リクエストを減らし、応答性を高めることができますか？その応答でHTTPリクエストの数を減らしたり、サーバーの負荷を減らしたりしないようです。
とにかく誰がこれを必要としますか？
主に帯域幅を節約する目的で使用されているというのは正しいですか？
目的は、サーバーではなくクライアントで帯域幅を節約することです。キャッシュできない AJAX リクエストは、訪問者にとって UI を非常に遅くする可能性が高く、データを何度も転送する必要がないため、クライアントのブラウザーでのパフォーマンスが大幅に向上します。
要求の数を減らしたい場合はExpires、応答に明示的なヘッダーを設定する必要があります。によって設定された時間がなくなるまで、クライアントはリソースを要求しませんExpires。
実装で常にdbクエリが必要な場合は、304を実装してもあまり効果がない可能性があります。応答のレンダリングに必要なリソースのみを節約している可能性があります。レンダリングに多くの処理が必要な場合は、dbクエリが必要な場合でも、それだけの価値がある可能性があります。
ただし、データベースを使用せずにリクエストURIを有効期限にマッピングするメカニズムがある場合は、応答時間の大幅な改善とサーバーリソースの節約に気付く可能性があります。
同様のシナリオを実装した方法は、すべてのリクエストをディスクにキャッシュすることでした。ファイルの最初の行（スキャンを必要としない方法で名前が付けられている）には、やなどのメタデータが含まれetagていttlます。ファイルの変更された時間とファイルにttl保存されている時間に基づいて、ディスクから1行だけを読み取ることで、304応答（クライアントを返す）、キャッシュファイルの内容（新しいクライアント、または最近のレンダリングを確認していないクライアントを返す）、または要求を処理して、通常、更新された結果を同時にキャッシュします。
304応答の実装の詳細については、この質問を参照してください。PHPでのHTTPConditionalGet Answersの実装は問題ありませんか？