Web開発を進めていくと、必ず「HTTPメソッド」という言葉に出会います。GETとPOSTはよく聞くけれど、PUTとPATCHの違いは？DELETEは何をどう消す？——このあたりは、なんとなく雰囲気で使ってしまいがちな領域です。
このコラムでは、主要なHTTPメソッドを一覧で整理したうえで、実際に手を動かして「何度送っても結果が変わらないメソッド」と「送るたびに結果が変わるメソッド」の違いを体験できるデモを用意しました。
HTTPメソッドとは、クライアント（ブラウザやアプリ）がサーバーに対して「何をしたいか」を伝えるための命令の種類です。
同じURL（例：/items/1）に対しても、どのメソッドで送るかによってサーバー側の処理はまったく異なります。
これを言葉ではなく「メソッド」という規格化された形で表現することで、サーバーやブラウザ、キャッシュサーバー、検索エンジンのクローラーなど、あらゆる関係者が同じルールで通信できるようになっています。
実務でよく使う7つのメソッドを一覧にしました。特に注目してほしいのが「べき等性」の列です。
| メソッド | 主な用途 | リクエストボディ | べき等性 | 安全性（読み取り専用） |
|---|---|---|---|---|
| GET | データの取得 | 基本なし | あり | あり |
| POST | 新規作成・処理の実行 | あり | なし | なし |
| PUT | リソースの丸ごと置換 | あり | あり | なし |
| PATCH | リソースの部分更新 | あり | 基本なし | なし |
| DELETE | リソースの削除 | 基本なし | あり | なし |
| HEAD | GETと同じだがボディなしで応答を確認 | なし | あり | あり |
| OPTIONS | そのURLが対応しているメソッドの確認 | 基本なし | あり | あり |
「べき等性（idempotency）」とは、同じリクエストを1回送っても100回送っても、サーバー側の最終的な状態が変わらないという性質です。これはネットワークが不安定でリクエストが重複してしまった場合などに、安全にリトライできるかどうかを左右する重要な概念です。
言葉で説明されてもピンとこないと思うので、実際に手を動かして確かめてみましょう。以下のデモは演出ではなく、疑似的な「在庫アイテムAPI」に対してGET・POST・PUT・PATCH・DELETEを送り、その場でリソースの状態を書き換えます（実際の通信は発生しません）。
下のボタンを連打して、数字の変化と結果メッセージを見比べてください。
ボタンを押すと、ここに結果と「べき等かどうか」が表示されます。
POSTを連打すると、押すたびにアイテムが増え続けたはずです。一方でPUTは、何度押してもstockが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・二重送信・セキュリティ）については、あわせて関連コラムもご覧ください。