HTTPリクエストメソッドの使い分け
「とりあえずPOSTで送ればいいか？」と迷ったときに、HTTPメソッドごとの役割をぱっと確認できるようにまとめました。RFC 9110（HTTP Semantics）に沿って、安全性や冪等性も押さえています。
まず押さえたいポイント
HTTPメソッドは「何をしたいか」を表す信号です。仕様（RFC 9110）に沿うと、キャッシュや中継サーバーの挙動が予測しやすくなります。
キーワード
- safe（安全）：サーバー側の状態を変えないことが期待されるメソッド（GET/HEAD/OPTIONS/TRACE）。ブラウザのプリフェッチやリンクプレビューで勝手に呼ばれても副作用が起きないようにする。
- idempotent（冪等）：同じリクエストを繰り返しても結果が変わらないことが期待されるメソッド（GET/HEAD/PUT/DELETE/OPTIONS/TRACE）。失敗時のリトライやネットワークの再送を安心して受けられる。
- PATCHはRFC 5789→RFC 9110に取り込まれた部分更新用のメソッド。冪等かどうかは実装次第なので、ETag＋If-Matchなどの条件付きリクエストを併用すると安全。
- レスポンスを共有キャッシュに載せられるのは基本的に安全メソッド。POSTでも明示的なキャッシュ指示で可能だが、実務では限定的。
主要メソッドの早見表
代表的なHTTPメソッドを用途・安全性・ボディの扱いで並べました（仕様はRFC 9110準拠）。
メソッド一覧
| メソッド | 主な用途 | 安全性/冪等性 | ボディ | キャッシュ |
|---|---|---|---|---|
| GET | リソース取得。ブラウザのリンク/画像取得もここ。 | safe / idempotent | 通常送らない（送れても意味は不定） | 可（Cache-Controlで制御） |
| HEAD | GETと同じ結果のヘッダーだけ確認。ヘルスチェックにも。 | safe / idempotent | 送らない | 可（GETと同等扱い） |
| POST | 作成・処理のトリガー。フォーム送信や非同期APIで利用。 | unsafe / not idempotent | 送る（Content-Type必須） | 通常しない（明示すれば可） |
| PUT | 指定リソースを丸ごと置き換え。 | unsafe / idempotent | 送る（完全な新状態を送信） | 一般にしない |
| PATCH | 部分更新。差分やパッチ形式を送る。 | unsafe / 非冪等（実装次第） | 送る（差分データ） | 一般にしない |
| DELETE | 削除要求。 | unsafe / idempotent（を期待） | 通常送らない | しない |
| OPTIONS | 通信可能かの問い合わせ。CORSプレフライトなど。 | safe / idempotent | 送れる（ほぼ空） | 可だが通常しない |
| TRACE | 経路で付与されたヘッダーを折り返すデバッグ用。 | safe / idempotent | 送らない | しない（多くのサーバーで無効化推奨） |
設計メモ
メソッドの性質を踏まえるとAPIやWebの振る舞いが読みやすくなります。
選び方の目安
- GETは副作用なしに徹する。リンクプレビューやブラウザの事前取得で勝手に呼ばれても安全にする。
- POSTは「新規作成や実行のトリガー」。同じ内容を二重送信される前提で、必要なら冪等性キーやリプレイ防止を用意する。
- PUTは「指定URIをこの内容で置き換える」。ボディは完全な最新状態を送る前提で、If-Matchなどの条件付き更新を合わせると更新競合を避けやすい。
- PATCHは「部分更新」。差分適用が複雑ならエンドポイントを明確に分け、If-Matchやリビジョン番号で整合性を守る。
- DELETEは「同じURLに同じリクエストを繰り返しても結果が変わらない」状態にする（冪等性）。すでに消えていても404ではなく204/200で返す設計も選択肢。
- OPTIONS/HEADはモニタリングや接続確認に便利。HEADはGETと同じヘッダーが返るよう実装を揃える。
よくある落とし穴と対策
フィールド運用で出やすいミスを先に押さえておくと安心です。
チェックポイント
- GETで状態を変える実装はNG。キャッシュやリンクプレビュー、検索エンジンのクロールで想定外の操作が走る。
- GETのボディはRFC上許容されるが意味が定義されないため避ける。パラメーターはクエリに載せる。
- POST/PUT/PATCHのContent-Typeを正しく指定（application/json, application/problem+jsonなど）。文字エンコーディングはUTF-8を明示。
- POSTを冪等に扱いたいときはIdempotency-Keyヘッダー（Stripeなどの設計で有名）を採用するなど対策を設計に組み込む。
- CORSプレフライト（OPTIONS）はキャッシュ可能（Access-Control-Max-Age）。レスポンスヘッダーを正しく返さないと毎回プリフライトが発生し遅くなる。
- TRACEはXST対策で無効化する構成が多い。必要なら認証が外れないように慎重に使う。
まとめ
HTTPメソッドの安全性と冪等性はRFC 9110で明確に定義されています。仕様に沿った使い分けにすると、キャッシュ/プロキシ/ブラウザの振る舞いが読みやすく、トラブルシュートもしやすくなります。