【実務・中級編】HTTPメソッドの安全性(Safety)とキャッシュ制御 – HTTPプロトコル・通信規格実践ガイド

「安全なメソッド」という幻想を捨てろ：HTTPメソッドのセマンティクスとキャッシュが織りなす危うい境界線

ネットワークエンジニアとして現場に立っていると、「GETリクエストでDBの値を更新してしまった」という、新人時代の悪夢のようなインシデントに時折遭遇します。RFC 7231（現行のHTTP/1.1セマンティクス）で定義されている「安全なメソッド（Safe Methods）」という概念は、単なるマナーや推奨事項ではありません。これが守られないとき、あなたのWebインフラはキャッシュによって予測不能な挙動を起こし、検索エンジンのクローラーはサイトの整合性を破壊し始めます。

今日は、HTTPの「安全なメソッド」という原則が、実務上のキャッシュ制御やAPI設計にどう影響を与えるのか、その深淵を覗いてみましょう。

—

1. 「安全」という定義の真の意味：Side Effectsを許すな

RFCの定義において、`GET` や `HEAD` は「安全」とされています。これは、「サーバーの状態（State）を変化させてはならない」という鉄の掟です。

なぜこれが重要か？それは、「クライアントは、安全なメソッドであれば何度リクエストを送っても、サーバーのデータも、ユーザーの体験も、何一つとして損なわれない」と信頼して通信を行うからです。

もし `GET /api/delete-user?id=123` のような設計をしてしまうと、以下のような悪夢が発生します。

プリフェッチの悲劇: ブラウザやモダンなフロントエンドフレームワークは、ユーザーがクリックする前に「先読み（Prefetch）」を行うことがあります。ユーザーがリンクに触れてもいないのに、勝手にリクエストが飛び、ユーザーが意図しない削除処理が実行されます。
キャッシュの暴走: CDNやブラウザキャッシュは、「安全なメソッドならキャッシュしても安全だ」と判断します。サーバー側で副作用を起こす実装をしていると、キャッシュの有効期限が切れるまで、その「破壊的副作用」が再実行され続けることになります。

—

2. キャッシュ制御とセマンティクスの連動

キャッシュの挙動を制御する `Cache-Control` ヘッダーと、メソッドの安全性は密接に関係しています。

HTTPリクエストのデバッグ（curl編）

まずは、現場でさっと確認するための `curl` コマンドです。`-v` オプションでヘッダーを詳細に見るのが基本中の基本です。

キャッシュの挙動を確認する
curl -Iv https://example.com/api/v1/resource \
-H “Cache-Control: no-cache” # キャッシュを無視してサーバーへ確認を強制

サーバーが「安全なメソッド」に対してどのようなキャッシュポリシーを返すべきか、以下の例を参考にしてください。

Nginxの設定例：APIレスポンスのキャッシュ制御
location /api/ {
# GETリクエスト以外（POST/PUT/DELETE）にはキャッシュを許可しない
add_header Cache-Control “no-store, no-cache, must-revalidate”;

# GETリクエストで、かつ変更頻度が低いリソースのみキャッシュを許容
if ($request_method = GET) {
add_header Cache-Control “public, max-age=3600”;
}
}

—

3. 実務で遭遇する「罠」：Fetch APIとクローラーの挙動

フロントエンドの開発において、`fetch` を使う際にもこの原則を忘れてはいけません。

// 良い例：状態を変更する際はPOSTを使用する
async function deleteResource(id) {
const response = await fetch(`/api/resource/${id}`, {
method: ‘POST’, // GETを使ってはいけない
headers: { ‘Content-Type’: ‘application/json’ },
body: JSON.stringify({ action: ‘delete’ })
});
return response.ok;
}

もし、これを `GET` で実装してしまうと、Googlebotのようなクローラーが「インデックス作成のためにページを巡回」した際、そのページにアクセスするたびにリソースが削除されるという、目も当てられない事態になります。

—

4. 現場のシニアからのアドバイス：どう設計すべきか

もしあなたがAPIを設計する立場なら、以下のチェックリストを常に意識してください。

1. 冪等性（Idempotency）と安全性を分ける: `GET` は「安全」かつ「冪等」。`PUT` は「非安全」だが「冪等」。`POST` は「非安全」かつ「非冪等」。このマトリクスを意識するだけで、APIの信頼性は劇的に向上します。
2. キャッシュキーの設計: サーバーの状態を読み出す `GET` リクエストに対しては、クエリパラメータを含めた適切な `Vary` ヘッダーを返すようにします。これにより、キャッシュの汚染（Cache Poisoning）を防げます。
3. ログを疑え: `GET` リクエストが大量に失敗している場合、それは単なるバグではなく、どこかのクローラーやプロキシが「副作用のあるGET」を叩き続けているサインかもしれません。アクセスログから `User-Agent` とメソッドの組み合わせを分析する習慣をつけてください。

—

終わりに：プロトコルは嘘をつかない

HTTPの仕様は、Webという巨大な分散システムを支えるための「共通言語」です。メソッドを適切に使い分けることは、単なる規約順守ではなく、あなたが構築するインフラを、世界のどこにいる誰からのアクセスに対しても「予測可能で堅牢なもの」にするための第一歩です。

教科書的な仕様を読み解くだけでなく、実際のパケットがどう流れ、キャッシュサーバーがどう反応し、クローラーがどう解釈するのか。その想像力を働かせることが、一流のエンジニアへの近道だと私は信じています。

何か具体的なトラブルや、設計で迷っていることがあれば、いつでもまた聞きに来てください。現場の最前線で待っています。