HTTPリクエストメソッドの使い分け

「とりあえずPOSTで送ればいいか？」と迷ったときに、HTTPメソッドごとの役割をぱっと確認できるようにまとめました。RFC 9110（HTTP Semantics）に沿って、安全性や冪等性も押さえています。

まず押さえたいポイント

HTTPメソッドは「何をしたいか」を表す信号です。仕様（RFC 9110）に沿うと、キャッシュや中継サーバーの挙動が予測しやすくなります。

safe（安全）：クライアントが状態変更を要求しない、基本的に読み取り用のメソッド（GET/HEAD/OPTIONS/TRACE）。アクセスログの記録などの付随動作まで禁止する意味ではありません。
idempotent（冪等）：同じ要求を繰り返したとき、サーバーへの意図した効果が1回の場合と同じになる性質（GET/HEAD/PUT/DELETE/OPTIONS/TRACE）。応答コードや本文が毎回同じとは限りません。
PATCHはRFC 5789で定義された更新用メソッドです。RFC 9110のメソッド定義へ統合されたわけではありません。冪等性は保証されず、操作内容によるため、必要に応じて強いETagとIf-Matchを併用します。
安全性とキャッシュ可否は別の性質です。GET/HEADは保存可能ですが、OPTIONS/TRACEは通常のHTTPキャッシュに保存できません。POST/PATCHは仕様上の条件を満たす必要があります。

代表的なHTTPメソッドを用途・安全性・ボディの扱いで並べました（PATCHはRFC 5789、その他はRFC 9110）。

保存にはステータス・ヘッダー等の条件もあります。POST/PATCHでは明示的な鮮度情報と対象URIに一致するContent-Locationが必要で、後続のGET/HEAD用に保存します。詳しくはキャッシュの条件を参照してください。OPTIONSのCORS専用キャッシュは後述します。

メソッドの性質を踏まえるとAPIやWebの振る舞いが読みやすくなります。

GETで購入・削除などの状態変更を要求する設計は避けます。リンクプレビューや事前取得でも呼ばれるためです。
POSTは「新規作成や実行のトリガー」。同じ内容を二重送信される前提で、必要なら冪等性キーやリプレイ防止を用意する。
PUTは「指定URIをこの内容で置き換える」。ボディは完全な最新状態を送る前提で、If-Matchなどの条件付き更新を合わせると更新競合を避けやすい。
PATCHは「部分更新」。差分適用が複雑ならエンドポイントを明確に分け、If-Matchやリビジョン番号で整合性を守る。
DELETEの冪等性は削除の効果についての性質です。初回204、2回目404でも、対象が削除された状態なら矛盾しません。再実行で別のデータまで消す設計は避けます。
HEADは本文を送らず、基本的にGETと同じヘッダーを返します。ただし本文生成時にしか決まらないヘッダーは省略できるため、完全一致が必須ではありません。

フィールド運用で出やすいミスを先に押さえておくと安心です。

GETに変更操作を割り当てると、キャッシュやリンクプレビュー、検索エンジンのクロールからも実行される危険があります。
GETの要求ボディに一般的な意味は定義されておらず、拒否されることもあります。通常はクエリを使い、機密情報や大きな検索条件を本文で送るなら、処理用のPOSTなどをAPIとして設計します。
本文がある要求では形式に合ったContent-Typeを送ります。JSONならapplication/jsonとし、システム間ではUTF-8で符号化します。application/jsonにcharsetパラメーターは定義されていません。PATCHは対応するパッチ形式を確認します。
POSTの二重処理を防ぐには、APIが対応する冪等性キーなどを使います。ヘッダーを付けるだけでは不十分で、サーバー側の保存期間、重複判定、同じキーで異なる内容を送った場合の扱いを決めます。
CORSの許可結果は通常のHTTPキャッシュとは別のプレフライトキャッシュに保存されます。Access-Control-Max-Ageはその寿命を指定します。未指定時にも短い既定値があり、必ず毎回送信されるわけではありません。
TRACEを使うクライアントは認証情報やCookieなどの機密情報を送ってはいけません。サーバーも機密フィールドを反射応答から除外します。

メソッドの性質と応答コード、キャッシュ条件を分けて考えましょう。ステータスコード早見表、キャッシュの条件、更新競合を防ぐ条件付き要求へ進むと、具体的な設計につながります。

< HTTPはHTML専用じゃない話 HTTPメソッド × ステータスコード早見表 >