🚀 はじめに

この記事でわかること

  • HTTPメソッド（GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS）の役割と違い
  • どのメソッドをいつ使うのが良いか（使い分け）
  • 身近なたとえと具体的なリクエスト例（curl／ブラウザfetch）で、イメージがつく

こんな人向け

  • 中学生〜大人まで、IT知識がほとんどない人
  • 「GETとPOSTって何が違うの？」「PUTとPATCHの違いがわからない」をスッキリさせたい人

初心者でも安心な理由

  • 難しい数式は使わず、生活のたとえで説明
  • 表・図・具体例でひと目で理解
  • 最後に公式リンクをまとめ、この記事だけでも完結します

注意：用語は正確さを優先しつつ、やさしい表現で説明しています。より厳密な定義は末尾の公式ドキュメントも参照してください。

✅ 概要解説

HTTPメソッドとは？

Webサーバーに「何をしてほしいか」を伝える“動詞（命令の種類）” です。

  • GET：見せて（読み取り）
  • POST：受け取って（新規作成・送信）
  • PUT：これに置き換えて（全体更新）
  • PATCH：ここだけ直して（部分更新）
  • DELETE：消して（削除）
  • HEAD：中身は要らないから情報だけ（ヘッダーだけ）
  • OPTIONS：何ができる？（許可される操作の確認／CORSの事前確認）
HTTPメソッドの全体像

何のためにあるの？

  • 役割分担：どんな操作かをはっきりさせると、サーバーやブラウザ、キャッシュ装置が正しく振る舞えます。
  • 安全性・効率：たとえばGETは原則「読むだけ」なので、キャッシュして速くできます。
  • 自動化・相互運用：機械（ツール・ライブラリ・プロキシ）が標準ルールに沿って動けます。

メソッドがないとどうなる？

  • 何でもかんでもPOSTにしてしまうと、キャッシュが効かない、再試行が危険、意図が伝わらないなどの問題が起きがち。
  • 例：本当は「読むだけ（GET）」なのにPOSTすると、無駄に重くて遅くなりやすい。

どんな場面で使えるの？

  • Web閲覧：ニュース記事を見る → GET
  • フォーム送信：お問い合わせを送る → POST
  • アプリの設定更新：設定を丸ごと上書き → PUT／一部だけ → PATCH
  • アカウント削除：→ DELETE
  • ダウンロード前のサイズ確認：→ HEAD
  • ブラウザのCORS確認（裏側で自動）：→ OPTIONS

ひと目でわかる！メソッド比較表

メソッドどんな操作？よくある用途安全性（読み取り専用？）冪等性（同じ操作を繰り返しても結果が同じ？）キャッシュ
GET資源を取得ページ表示、一覧取得安全冪等可（デフォルトで可）
POSTデータ送信・新規作成フォーム送信、注文作成非安全非冪等通常不可（明示すれば可）
PUT全体を上書きプロフィールを丸ごと更新非安全冪等条件により可
PATCH一部を更新名前だけ変更など非安全非冪等（原則）通常不可
DELETE削除投稿削除、退会非安全冪等不可
HEADヘッダーのみ取得サイズ/存在確認、ヘルスチェック安全冪等可
OPTIONS許可メソッド確認CORSプリフライト安全冪等実装依存

用語ミニ解説

  • 安全（safe）：読むだけで、サーバー側の状態を変えない約束。
  • 冪等（べきとう／idempotent）：同じリクエストを何回送っても結果が同じ（ログは増える等の副作用は別）。
  • キャッシュ：取得結果を手元に保存して、次回は速く返す仕組み。

各メソッドをやさしく深掘り

GET：見るだけ（読み取り）

  • 例：ニュース記事を開く、プロフィールを表示
  • 安全・冪等・キャッシュ可
  • URLのクエリ（?q=abc） で検索条件などを渡すのが一般的

例（記事一覧を取得）

# 例：記事一覧を取得（GET）
curl -X GET "https://api.example.com/articles?limit=10"

注意：GETでリクエストボディを送る仕様はありますが、一般には使いません（多くのサーバー・プロキシが想定していないため非互換の原因になります）。

POST：受け取って（新規作成・送信）

  • 例：問い合わせ送信、新規注文、ログイン
  • 非安全・非冪等（同じ注文を2回送ると2件になるかも）
  • フォームの標準動作として広く使われます

例（新規記事を作成）

# 例：新規記事の作成（POST）
curl -X POST "https://api.example.com/articles" \
  -H "Content-Type: application/json" \
  -d '{"title":"はじめてのHTTP","body":"メソッド入門"}'

ヒント：POSTは「何でも袋」になりがち。作成ならPOST、更新はPUT/PATCHと役割分担すると後でわかりやすくなります。

PUT：これに置き換えて（全体更新）

  • 指定の場所（URI）に完全版を置くイメージ
  • 冪等：同じ内容を何度送っても結果は同じ
  • 使い所：リソース全体を上書きしたいとき

例（プロフィールを丸ごと更新）

# 例：プロフィールを全置換（PUT）
curl -X PUT "https://api.example.com/profile/123" \
  -H "Content-Type: application/json" \
  -d '{"name":"Hanako","email":"[email protected]","bio":"Hello!"}'

注意：PUTは送った内容だけが正。未指定の項目が消える設計も多いので要注意（API仕様を確認）。

PATCH：ここだけ直して（部分更新）

  • 一部だけ直したいとき
  • 送るデータは変更差分（形式はAPIごとに決まりあり：JSON Merge Patch / JSON Patch など）

例（名前だけ変更）

# 例：名前だけ部分更新（PATCH）
curl -X PATCH "https://api.example.com/profile/123" \
  -H "Content-Type: application/json" \
  -d '{"name":"Hanako Y."}'

コツ：仕様で差分形式を決めると実装がブレません（例：application/merge-patch+json）。

DELETE：消して（削除）

  • 投稿削除、ファイル削除など
  • 冪等：2回目以降は「もう無いよ」と返るだけで、結果は変わらない

例（記事を削除）

# 例：記事を削除（DELETE）
curl -X DELETE "https://api.example.com/articles/42"

実務の注意：完全削除が怖い場合はソフトデリート（フラグだけ立てる）を採用することも多いです。

HEAD：情報だけ（ボディなし）

  • GETと同じ処理だが、本文なしでヘッダーだけ返す
  • ダウンロード前にサイズ確認（Content-Length）、存在確認、ヘルスチェックなどに

例（ファイルサイズを知る）

# 例：HEADでサイズだけ確認
curl -I "https://example.com/bigfile.zip"

OPTIONS：何ができる？（許可確認）

  • サーバーや特定のURLが受け付けるメソッドやCORSの許可を確認
  • ブラウザが自動で送ることが多い（プリフライト）

例（CORSプリフライトのイメージ）

# ブラウザが内部で送る例（開発者は通常書かない）
OPTIONS /api/articles HTTP/1.1
Origin: https://your-frontend.example
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

ポイント：フロントエンドからAPIを呼ぶ時、CORSエラーで詰まる場合はOPTIONSのレスポンスヘッダー（Access-Control-Allow-*）設定を確認。

💡 小話・豆知識・逸話

  1. GETは“安全”、DELETEは“冪等”

    • 「安全」＝読取り専用の約束。
    • 「冪等」＝同じ操作を繰り返しても結果は同じ。
    • なのでDELETEは冪等（2回削除しても最終状態は「無い」）。
      （用語が混ざりやすいので要注意）

  2. PUT vs PATCHは“丸ごと”か“部分”か

    • PUT：全置換、PATCH：部分更新。
    • フロントもバックもどっちを採用するか最初に決めると混乱が減ります。

  3. ブラウザのHTMLフォームはGETとPOSTが基本

    • フォーム単体ではPUT/PATCH/DELETEは直接送れない（JSやサーバー側ルーティングで対応）。

  4. POSTもキャッシュできることはある

    • ヘッダーで明示すれば可能。ただし標準はGET中心。
    • 「どうしても高速化したい」場合はAPI設計とキャッシュ戦略をセットで。

  5. HEADは“通信量の節約”にも効く

    • 大きなファイルの前座チェックに便利。
    • ただし一部CDN/サーバーはHEADをGETにフォールバックすることもあるので挙動確認を。

実例で理解：ブラウザfetchのミニサンプル

/** GET：記事を読み取る **/
fetch("https://api.example.com/articles?limit=5")
  .then(r => r.json())
  .then(list => console.log(list));

/** POST：記事を作る **/
await fetch("https://api.example.com/articles", {
  method: "POST",
  headers: {"Content-Type": "application/json"},
  body: JSON.stringify({ title: "HTTP超入門", body: "今日はGETとPOSTの話" })
});

/** PUT：プロフィールを全置換 **/
await fetch("https://api.example.com/profile/123", {
  method: "PUT",
  headers: {"Content-Type": "application/json"},
  body: JSON.stringify({ name: "Taro", email: "[email protected]", bio: "" })
});

/** PATCH：名前だけ変更 **/
await fetch("https://api.example.com/profile/123", {
  method: "PATCH",
  headers: {"Content-Type": "application/json"},
  body: JSON.stringify({ name: "T. Yamada" })
});

/** DELETE：記事を削除 **/
await fetch("https://api.example.com/articles/42", { method: "DELETE" });

CORSの壁で失敗する場合：ブラウザから呼ぶとサーバー側にCORS許可ヘッダーが必要です（Access-Control-Allow-Originなど）。同じAPIでもcurlだと成功・ブラウザだと失敗がありえます。

📚 参考リンク

公式ドキュメント（標準）

MDN Web Docs（実務にやさしい解説）

Wikipedia（背景理解）

信頼できる外部情報（設計・実践）

参考の使い方：まずはMDNの日本語ページ→ さらに深掘りしたくなったらRFCへ、の順がおすすめです。

🛠️ 関連テーマ・次に理解すると良いこと

🎯 まとめ

  • HTTPメソッドは“何をしてほしいか”を伝える動詞。
  • GET＝読むだけ／POST＝送信・作成／PUT＝全置換／PATCH＝部分更新／DELETE＝削除／HEAD＝情報だけ／OPTIONS＝何ができる？
  • 安全性・冪等性・キャッシュ性を理解すると、速くて壊れにくいAPI設計ができる。
  • ブラウザからのAPI呼び出しではCORSが関わる（うまくいかない時は許可ヘッダーを確認）。
  • 迷ったら 「何をしたいか」→ 対応メソッドの順で選び、詳細はMDNとRFCで裏を取る。