安全なHTTPメソッド — 読み取り専用の保証

メソッドが「安全」であるとは？

HTTPメソッドが安全であるとは、サーバーの状態を変更しないことです。リクエストは純粋に読み取り専用です。GET、HEAD、OPTIONS、TRACEが安全なメソッドです。

安全性マトリクス

メソッド	安全	理由
GET	はい	データの取得のみ
HEAD	はい	GETと同じ、ボディなし
OPTIONS	はい	機能を記述
TRACE	はい	リクエストをエコーバック
POST	いいえ	リソースを作成/アクションをトリガー
PUT	いいえ	リソースを置換
PATCH	いいえ	リソースを変更
DELETE	いいえ	リソースを削除
CONNECT	いいえ	トンネルを確立

安全性が重要な理由

ブラウザはメソッドの安全性に依存します：

• プリフェッチ — ブラウザは<link rel="prefetch"> URLをGETで投機的にフェッチでき、副作用がないことを知っている
• バック/フォワードキャッシュ — キャッシュされたGETレスポンスは履歴ナビゲーション時に再利用できる
• クローラー — 検索エンジンはリンク（GETリクエスト）をたどり、データを変更する恐れがない

プロキシとCDNは安全性を活用します：

• キャッシュ — 安全なメソッドはデフォルトでキャッシュ可能
• リトライ — 安全なリクエストは失敗時に結果を心配せずリトライできる
• 接続プーリング — 複数の安全なリクエストが自由に接続を共有できる

よくある間違い

1. GETで状態変更 — GET /api/delete-user/42は安全性の契約に違反。クローラーがこのリンクをたどるとユーザーが削除される。
2. POSTで読み取り — 有害ではないが、キャッシュを防ぎ、ブラウザのナビゲーション期待に反する。
3. GETハンドラーでの副作用 — ページビューのログ記録はぎりぎり許容されるが、GETハンドラーからレコードを作成したりメールを送信するのは違反。

実践的なルール

リクエストがデータの読み取りのみの場合、GETまたはHEADを使用します。データを変更する場合、POST、PUT、PATCH、DELETEを使用します。これにより、クライアント、プロキシ、ブラウザにとってAPIが予測可能になります。