【入門編】HTTP/1.1のメソッド（GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE） – HTTPプロトコル・通信規格実践ガイド

郵便局員も驚く？HTTPメソッドの「役割」と「お約束」をマスターしよう

こんにちは！インフラの世界へようこそ。今日はWebブラウザとサーバーが会話をするための共通言語、「HTTPメソッド」についてお話しします。

「HTTPメソッド」と聞くと難しく感じるかもしれませんが、要は「サーバーへの依頼内容」のことです。例えば、あなたが手紙を出すとき、郵便局に「届けて！」と言うのか、「内容を書き換えて！」と言うのか、あるいは「届いているか確認して！」と言うのか。その指示を明確にするためのルールが、HTTPメソッドなのです。

さあ、パケットがネットワークを駆け巡るイメージを持ちながら、一歩ずつ紐解いていきましょう！

—

1. HTTPメソッドは「郵便物」の宛名書きと同じ

HTTP/1.1で定義された主要なメソッドには、それぞれ明確な役割があります。まずは身近な郵便物に例えて見てみましょう。

GET（ゲット）: 「中身を見せて！」（カタログを請求するイメージ）
POST（ポスト）: 「新しいものを追加して！」（注文書を送るイメージ）
PUT（プット）: 「これをここに置いて！」（指定した場所に荷物を配置するイメージ）
DELETE（デリート）: 「これを消して！」（古い書類を破棄するイメージ）

これらは日常のやり取りと全く同じ感覚ですよね。でも、ネットワークエンジニアとしてここから先、絶対に覚えておかなければならない「二つの重要なルール」があるんです。それが「安全性」と「冪等性（べきとうせい）」です。

—

2. インフラエンジニアが泣いて喜ぶ「安全性」と「冪等性」

トラブルシューティングの現場では、この二つの概念を知っているだけで、原因の切り分けスピードが劇的に変わります。

安全性（Safety）

「その操作を行っても、サーバーの状態は変わらないよね？」という保証のことです。

GETやHEADは「見るだけ」なので、何度繰り返してもサーバーの中身は変わりません。だから「安全」と言います。

冪等性（Idempotency）

「何回実行しても、結果は同じだよね？」という保証のことです。

例えば、PUTで「このデータをこの場所に置け」と10回指示しても、結局そこに置かれるデータは一つです。これが「冪等」です。
一方、POSTは「追加」なので、10回実行すれば10個データが追加されてしまいます。だからPOSTは「冪等ではない」のです。

「なぜこれが重要なのか？」というと、通信エラーが起きたときの判断基準になるからです。ブラウザが「送信できたかな？」と不安になったとき、GETなら何度リトライしても安全ですが、POSTなら「二重注文」になってしまう危険がありますよね。この設計思想が、現代のWebアプリケーションを支えているんです。

—

3. 実務で役立つメソッドの使い分け

では、開発現場でよく使われるメソッドを実際のコードの雰囲気で見てみましょう。

実際のリクエストイメージ（ブラウザからサーバーへの命令）

// GET: データを取得する（安全かつ冪等）
// 例：商品を検索する
GET /products/123 HTTP/1.1

// POST: 新規作成する（安全ではないし、冪等でもない）
// 例：新しいユーザーを登録する
POST /users HTTP/1.1
{ “name”: “田中太郎” } // サーバーはこのデータを追加する

// PUT: データを更新・配置する（冪等）
// 例：ユーザーの住所を書き換える
PUT /users/123 HTTP/1.1
{ “address”: “東京都新宿区…” }

// DELETE: データを削除する（冪等）
// 例：商品ID 123を削除する
DELETE /products/123 HTTP/1.1

※ HEADはGETと似ていますが、中身（ボディ）は返さず「ヘッダー情報（サイズや更新日など）」だけを返します。通信量を節約したいインフラの現場で、「ファイルが存在するか確認する」ときによく使われるテクニックです。

—

4. 現場からのアドバイス： OPTIONSとTRACEはどう使う？

少しマニアックですが、現場でたまに見かけるのがOPTIONSとTRACEです。

OPTIONS: 「このサーバー、どんなメソッドを受け付けてくれるの？」と確認するメソッド。Webサイトのセキュリティ（CORS）設定で「許可された操作か？」を事前にチェックする際によく登場します。
TRACE: サーバーに届いたリクエスト内容をそのまま返してもらうメソッド。パケットが途中のプロキシサーバーなどで改ざんされていないか確認する「鏡」のような役割を果たします。ただし、セキュリティ上の理由から最近は無効化されていることが多いので、見かけたら「あ、診断用だな」と思ってください。

—

まとめ：ネットワークは「対話」である

HTTPメソッドの理解は、単なるプログラミングの知識ではありません。「ネットワークの向こう側にいるサーバーとの約束事」を理解することです。

「この操作は安全かな？」「エラーが起きたとき、もう一回送っても大丈夫な命令かな？」

そうやってパケットの流れを想像できるようになれば、あなたはもう一人前のインフラエンジニアです。もしトラブルが発生しても、メソッドの特性を理解していれば、「あ、これはPUTだから何度リトライしても大丈夫だ」と冷静に判断できるはずです。

これからも一歩ずつ、パケットの向こう側にある「対話」を楽しんでいきましょう！