【ネットワーク】 HTTPメソッド（GET・POST・PUT・DELETE）の使い分け

ネットワーク
2022.04.07

こんにちは、かつコーチです。

前回の記事で、HTTPは「依頼状（リクエスト）と返信（レスポンス）のやり取り」だと解説しました。
では、その依頼状には具体的にどんな「依頼の種類」があるのでしょうか。
この記事では、代表的なHTTPメソッドであるGET・POST・PUT・PATCH・DELETEの違いと使い分けを、中級者向けに解説します。
使い分けを理解すると、API設計やフォーム実装で迷わなくなります。

HTTPメソッドとは？

依頼の種類を表すラベル

HTTPメソッドとは、HTTPリクエストの先頭に書かれる、「サーバーに何をしてほしいか」を表す動詞のようなラベルです。

手紙のやり取りに例えるなら、依頼状の一番上に「見せてほしい」「送りたい」「直してほしい」「消してほしい」といった依頼の種類を明記するイメージです。
受け取った側（サーバー）は、この依頼の種類を見るだけで、本文を細かく読まなくても「何をすればいいか」を機械的に判断できます。

なぜメソッドを使い分ける必要があるのか

もしすべての依頼が同じ種類だったら、サーバー側は毎回、依頼状の中身を丁寧に読んで「これは閲覧の依頼だな」「これはデータ登録の依頼だな」と判断しなければなりません。
あらかじめ依頼の種類をラベルとして明示しておけば、サーバー側の処理も、通信経路上のキャッシュサーバーなどの中継役も、効率よく適切な対応を取れるようになります。

代表的なHTTPメソッドの使い分け

GET：情報を見せてほしいという依頼

GETは、サーバーの状態を変えずに、情報を取得するための依頼です。
「このページを見せてほしい」「この商品一覧を見せてほしい」といった、閲覧目的の依頼にあたります。

# GETリクエストで商品一覧を取得する例
curl -X GET https://api.example.com/products

POST：新しいデータを送りたいという依頼

POSTは、サーバーに新しいデータを送信し、登録・作成してもらうための依頼です。
「この内容で新規会員登録をしたい」「この投稿を新しく作りたい」といった依頼にあたります。

# POSTリクエストで新しい商品を登録する例
curl -X POST https://api.example.com/products \
  -H "Content-Type: application/json" \
  -d '{"name": "サンプル商品", "price": 1000}'

PUT・PATCH：既存のデータを直してほしいという依頼

PUTとPATCHは、どちらも既存のデータを更新するための依頼ですが、直し方の範囲が異なります。
PUTは「この内容にまるごと差し替えてほしい」という全体の上書きの依頼です。
PATCHは「この部分だけ直してほしい」という部分的な修正の依頼です。

# PUTリクエストで商品情報をまるごと更新する例
curl -X PUT https://api.example.com/products/1 \
  -H "Content-Type: application/json" \
  -d '{"name": "サンプル商品", "price": 1200}'

# PATCHリクエストで価格だけを更新する例
curl -X PATCH https://api.example.com/products/1 \
  -H "Content-Type: application/json" \
  -d '{"price": 1200}'

DELETE：データを消してほしいという依頼

DELETEは、指定したデータを削除するための依頼です。
「この投稿を消してほしい」といった依頼にあたります。

# DELETEリクエストで商品を削除する例
curl -X DELETE https://api.example.com/products/1

べき等性という判断軸

同じ依頼を繰り返しても結果が変わらないか

メソッドを使い分けるうえで重要な判断軸がべき等性（idempotency）です。
これは「同じ依頼を1回送っても複数回送っても、サーバー側の最終的な結果が変わらない性質」を指します。

メソッドべき等性手紙で例えると
GETあり何度見せてもらっても状態は変わらない
PUTあり同じ内容で何度上書きしても結果は同じ
DELETEあり一度消えたものを何度消そうとしても結果は同じ
POSTなし同じ依頼状を2通送ると、2件分登録されてしまう
PATCH基本的になし「1件追加して」のような依頼だと、送るたびに結果が変わりうる

POSTがべき等でない点は、特に初中級者がつまずきやすいポイントです。
「送信ボタンを二重にクリックしてしまい、同じ注文が2件登録された」というトラブルは、まさにPOSTのこの性質が原因です。

よくあるつまずきポイント・エラー対処

PUTとPATCHを混同して意図せずデータを消してしまう

❌Before（つまずいた実例）

価格だけを更新したいつもりで、PATCHではなくPUTを使ってAPIを呼び出したところ、リクエストボディに含めなかった商品名のフィールドが空になってしまったことがあります。

# 価格だけ直したいのにPUTで一部のフィールドしか送らなかった例
curl -X PUT https://api.example.com/products/1 \
  -H "Content-Type: application/json" \
  -d '{"price": 1200}'
# → nameフィールドが消えてしまう

✅After（解決方法）

PUTは「まるごと差し替え」の依頼だと理解し、部分更新にはPATCHを使うよう修正したところ、意図しないデータ消失を防げました。

# 部分更新にはPATCHを使う
curl -X PATCH https://api.example.com/products/1 \
  -H "Content-Type: application/json" \
  -d '{"price": 1200}'

「PUTは手紙をまるごと書き直して送る依頼、PATCHは既存の手紙に付箋で修正指示を出す依頼」と考えると、混同を防ぎやすくなります。

応用・一歩先の使い方

RESTful APIにおけるメソッドの設計指針

Web APIを設計する際は、URLは「対象（リソース）」を表し、操作の種類はHTTPメソッドで表す、という役割分担を意識すると一貫性のある設計になります。

GET    /products      # 商品一覧を見せてほしい
POST   /products      # 新しい商品を登録したい
GET    /products/1    # 商品1件を見せてほしい
PUT    /products/1    # 商品1件をまるごと更新したい
PATCH  /products/1    # 商品1件の一部を更新したい
DELETE /products/1    # 商品1件を消してほしい

URLにcreateやdeleteといった動詞を含めず、メソッド側に依頼の種類を語らせるのが、RESTfulなAPI設計の基本的な考え方です。

まとめ

この記事のポイント

  • HTTPメソッドは、依頼状に書く「何をしてほしいか」を表すラベル
  • GET＝見せて、POST＝送って登録、PUT＝まるごと直して、PATCH＝一部直して、DELETE＝消して、と対応する
  • べき等性（同じ依頼を繰り返しても結果が変わらないか）は、GET・PUT・DELETEにはあるが、POSTにはない
  • PUTとPATCHを混同すると、意図せずデータが消える事故につながるため注意する

次に読むべき記事

HTTPメソッドの使い分けがわかったら、次は「HTTPSとは？SSL/TLSで通信を暗号化する仕組み」で、通信の安全性について学んでみてください。

タグ: ネットワーク, 中級者向け, HTTP

タイトルとURLをコピーしました