Web APIの「無駄な通信」を削ぎ落とせ：Last-ModifiedとIf-Modified-Sinceで構築するスマートなキャッシュ戦略
現場でAPIのパフォーマンスチューニングをしていると、必ずぶち当たる壁がある。「なぜ、変わってもいないデータを毎回フルサイズで転送しているんだ？」という自問自答だ。
今日は、HTTPヘッダーの古典にして、今なおWebの骨格を支えるLast-ModifiedとIf-Modified-Sinceによるキャッシュ検証について掘り下げていこう。RFC 7232（HTTP/1.1 Conditional Requests）の深淵を覗きつつ、現場でエンジニアが陥りやすい罠と、それを回避する「実戦的」な設計思想を伝授する。
—
1. 原理原則：サーバーとクライアントの「時刻」による握手
この仕組みの美しさは、サーバーが送る「最終更新日時」をクライアントが記憶し、次回以降のリクエストで「この日時以降に変わった？」と問い合わせるという、極めてシンプルな対話にある。
通信のシーケンス
1. 初回リクエスト: クライアントがリソースを要求。サーバーは 200 OK とともに Last-Modified ヘッダーを返す。
2. キャッシュ保存: クライアントはレスポンスボディと Last-Modified の値をローカルに保存する。
3. 条件付きリクエスト: 次回、クライアントは保存しておいた日時を If-Modified-Since ヘッダーに乗せて送る。
4. 検証: サーバーはリソースの更新日時と比較する。
- 変更なし:
304 Not Modifiedを返す（ボディは空。ここが肝だ）。 - 変更あり:
200 OKと新しいデータを返す。
この 304 Not Modified が返るだけで、ネットワーク帯域とサーバーのCPU負荷は劇的に削減される。数ミリ秒のレイテンシを削り出すことに命を懸ける我々にとって、必須の武器だ。
—
2. 実務で遭遇する「悪魔の細部」
教科書通りにいかないのが現場だ。特に注意すべきは以下の2点である。
1. ETagとの優先順位
HTTPの仕様上、If-None-Match（ETag）が存在する場合、サーバーは通常こちらを優先する。Last-Modified は「時刻」という曖昧な概念に依存するため、ETag（ハッシュ値による厳密な比較）の方が信頼性が高いからだ。設計時には ETag と Last-Modified を併用するのがベストプラクティスだ。
2. システムクロックの「ズレ」という地雷
分散サーバー環境でNTPの同期が甘いと、Aサーバーで書き込んだ時刻が、Bサーバーから見ると「未来」になってしまうことがある。これが起きるとキャッシュが正しく効かないばかりか、整合性エラーの温床になる。
対策: データベース上の最終更新日時（updated_at 等）をソース・オブ・トゥルース（信頼できる唯一の情報源）とし、サーバーのOS時刻に依存しないロジックを組むこと。
—
3. 実践：Python (Flask) による実装例
APIサーバーサイドの実装は、いかに効率よく「更新判定」を行うかが鍵だ。
from flask import Flask, request, make_response
from datetime import datetime
app = Flask(__name__)
# 仮のデータ更新時刻
LAST_UPDATED = datetime(2023, 10, 27, 10, 0, 0)
@app.route('/resource')
def get_resource():
# クライアントからのIf-Modified-Sinceヘッダーを取得
if_modified_since = request.headers.get('If-Modified-Since')
if if_modified_since:
# ヘッダーの時刻をパース（RFC 1123形式）
# 実際には適宜パースエラーハンドリングが必要
client_time = datetime.strptime(if_modified_since, '%a, %d %b %Y %H:%M:%S GMT')
# サーバーのデータ更新日時と比較
if LAST_UPDATED <= client_time:
return '', 304 # 変更なしならボディなしで304を返す
# 変更あり、またはキャッシュなしの場合はデータを生成
response = make_response("最新のコンテンツデータ")
response.headers['Last-Modified'] = LAST_UPDATED.strftime('%a, %d %b %Y %H:%M:%S GMT')
return response—
4. デバッグの現場：curlで挙動を叩く
フロントエンドやモバイルアプリからリクエストを送る前に、まずは curl でプロトコルの挙動を裸にしよう。
# 1回目：ヘッダーを確認
curl -I https://api.example.com/resource
# 2回目：前回のLast-ModifiedをIf-Modified-Sinceにセットして投げる
curl -I -H "If-Modified-Since: Fri, 27 Oct 2023 10:00:00 GMT" https://api.example.com/resourceここで HTTP/1.1 304 Not Modified が返ってくれば、実装は成功だ。もし 200 OK が返ってくるなら、サーバー側の比較ロジック（if LAST_UPDATED <= client_time:）を見直すべきだ。
—
最後に：ネットワークエンジニアとしての美学
Web APIの設計において、HTTPヘッダーを使いこなすことは、単なる「技術の適用」ではない。それは、限られた通信資源を最大限に尊重し、ユーザーの体験を少しでも快適にするという、エンジニアとしての倫理観の現れだ。
「とりあえず全データを投げつける」APIは初心者でも作れる。だが、キャッシュ戦略まで設計されたAPIは、長期的な運用において必ずサーバーコストとトラフィックの面で投資以上のリターンをもたらす。
次回のコードレビューで、もし君が後輩の書いたコードに Cache-Control や条件付きリクエストの影がないのを見つけたら、この話をぜひ思い出してほしい。泥臭いパケットの検証こそが、最強のエンジニアへの近道だと。
コメント