Web開発を進めていくと、必ず「HTTPメソッド」という言葉に出会います。GETとPOSTはよく聞くけれど、PUTとPATCHの違いは？DELETEは何をどう消す？——このあたりは、なんとなく雰囲気で使ってしまいがちな領域です。
このコラムでは、主要なHTTPメソッドを一覧で整理したうえで、実際に手を動かして「何度送っても結果が変わらないメソッド」と「送るたびに結果が変わるメソッド」の違いを体験できるデモを用意しました。
HTTPメソッドとは、クライアント（ブラウザやアプリ）がサーバーに対して「何をしたいか」を伝えるための命令の種類です。
同じURL（例：/items/1）に対しても、どのメソッドで送るかによってサーバー側の処理はまったく異なります。
これを言葉ではなく「メソッド」という規格化された形で表現することで、サーバーやブラウザ、キャッシュサーバー、検索エンジンのクローラーなど、あらゆる関係者が同じルールで通信できるようになっています。
実務でよく使う7つのメソッドを一覧にしました。特に注目してほしいのが「べき等性」の列です。
| メソッド | 主な用途 | 具体例 | リクエストボディ | べき等性 | 安全性（読み取り専用） |
|---|---|---|---|---|---|
| GET | データの取得 | 商品一覧やブログ記事を表示する | 基本なし | あり | あり |
| POST | 新規作成・処理の実行 | 会員登録フォームの送信、購入確定 | あり | なし | なし |
| PUT | リソースの丸ごと置換 | プロフィールを全項目まとめて保存 | あり | あり | なし |
| PATCH | リソースの部分更新 | タスクの「完了」チェックだけON/OFF | あり | 基本なし | なし |
| DELETE | リソースの削除 | カートから商品を1つ削除する | 基本なし | あり | なし |
| HEAD | GETと同じだがボディなしで応答を確認 | ファイルサイズや更新日時だけ確認 | なし | あり | あり |
| OPTIONS | そのURLが対応しているメソッドの確認 | CORS通信の事前確認（プリフライト） | 基本なし | あり | あり |
「リクエストボディ」とは、リクエストを送る際にサーバーへ渡すデータ本体のことです。GETは基本的にボディを使わず、必要な情報は?key=valueのようにURLのクエリパラメータに載せます。POST・PUT・PATCHは、新規作成したいデータや変更したい内容をJSON形式などでボディに入れて送信します。
「べき等性（idempotency）」とは、同じリクエストを1回送っても100回送っても、サーバー側の最終的な状態が変わらないという性質です。これはネットワークが不安定でリクエストが重複してしまった場合などに、安全にリトライできるかどうかを左右する重要な概念です。
「安全性（読み取り専用）」とは、そのメソッドを実行してもサーバー側のデータが一切変化しないという性質です。GET・HEAD・OPTIONSは「安全」に分類され、ブラウザの先読みや検索エンジンのクローラーが確認なしに送信しても問題ありません。POST・PUT・PATCH・DELETEは何らかの変更を伴うため「安全」ではありません。
なお「安全」なメソッドは必ず「べき等」でもありますが、逆は成り立ちません。PUTとDELETEは「べき等」ではあってもデータを変更する以上「安全」ではない、という点が紛らわしいポイントです。
言葉で説明されてもピンとこないと思うので、実際に手を動かして確かめてみましょう。以下のデモは演出ではなく、疑似的な「在庫アイテムAPI」の棚（/items）に対してGET・POST・PUT・PATCH・DELETEを送り、その場で棚の中身を書き換えます（実際の通信は発生しません）。
下のボタンを押すと、棚（在庫アイテムAPI）の様子がその場で変化します。何度も連打して、箱の動き方を見比べてください。
ボタンを押すと、棚の様子が変化します。
POSTを連打すると、押すたびに新しい箱が棚に増え続けたはずです。一方でPUTは、何度押しても在庫バッジが10という同じ場所に戻ります。これが「べき等ではないPOST」と「べき等なPUT」の違いです。PATCHは実装次第でどちらにもなり得ますが、このデモのように「+1する」実装にすると、PUTとは違って押すたびに数字が増え続けてしまいます。DELETEは、1回目で箱が消え、2回目以降は「もう無い」という同じ結果が返り続けます。これも立派な「べき等」の一例です。
ここからは、先ほどの一覧表に登場した7つのメソッドを、実務でどう使い分けるべきかという観点であらためて整理します。それぞれの用途とべき等性の関係を意識しながら見ていきましょう。
ページの表示、一覧の取得、検索結果の表示など、サーバー側のデータを変更しない処理はすべてGETです。ブラウザの「戻る」やブックマーク、検索エンジンのクローラーはGETであることを前提に動くため、GETで状態を変更する実装は事故のもとになります。
会員登録、注文確定、コメント投稿など「新しく何かを生み出す」処理や、決済のように「1回きりであるべき処理」に使います。POSTはべき等ではないため、二重送信対策（連打防止・トークンチェックなど）が必要になる場面が多いメソッドです。
「そのリソースが最終的にどうなっているべきか」をすべて指定して送り、サーバー側はそれで丸ごと上書きします。一部の項目だけを送っても、送らなかった項目は消えたり初期化されたりする実装が一般的です。
「ここだけ直したい」という部分更新に使います。PUTと違って、送っていない項目はそのまま残ります。ただし前述の通り、実装によってはべき等にならない点に注意が必要です。
リソースの削除に使います。「すでに削除済みのものをもう一度削除しても、結果（＝存在しない）は変わらない」という意味でべき等に分類されます。
HEADはGETと同じ処理をしつつ、レスポンスボディを返さずヘッダーだけを確認したいときに使います。ファイルサイズや更新日時だけを知りたい場合などに便利です。OPTIONSは「このURLはどのメソッドに対応しているか」をサーバーに問い合わせるためのメソッドで、CORS通信の事前確認（プリフライトリクエスト）でも使われています。
実務で最も事故が起きやすいのは、やはりGETとPOSTの使い分けです。CSRFやログ漏洩など、設計ミスが具体的にどんな事故につながるのかは、 GETとPOSTの違いとセキュリティ で詳しく解説しています。
HTTPメソッドは、単なる「送り方の種類」ではなく、「サーバーに何をしてほしいか」という約束事です。
特に重要なのは、べき等性という考え方です。GET・PUT・DELETEは「何度実行しても同じ結果」、POSTと（実装によっては）PATCHは「実行するたびに結果が変わりうる」——この違いを理解しておくだけで、リトライ処理やAPI設計での事故をかなり防げます。
GETとPOSTのより実務的な注意点（CSRF・二重送信・セキュリティ）については、あわせて関連コラムもご覧ください。