HTTPメソッド - GET / POST / PUT / DELETE / PATCH の使い分け

HTTPメソッドとは

HTTPメソッドは、クライアントがサーバーのリソースに対して「何をしたいか」を示す動詞です。リクエストラインの最初に記述されます。

GET /api/users/123 HTTP/1.1
^^^
メソッド

リソース指向: HTTPメソッドは、URLで指定したリソース（データ）に対する操作を表現します。

主要メソッド一覧

GET - リソースの取得

サーバーからデータを取得する際に使用します。最も基本的で、最も多く使われるメソッドです。

特徴

• 安全: サーバーの状態を変更しない
• 冪等: 何度実行しても同じ結果
• キャッシュ可能: ブラウザやCDNがキャッシュできる
• リクエストボディ: 通常は使用しない

使用例

# ユーザー一覧を取得
GET /api/users HTTP/1.1
Host: api.example.com

# 特定のユーザーを取得
GET /api/users/123 HTTP/1.1

# クエリパラメータでフィルタリング
GET /api/products?category=books&sort=price&limit=20 HTTP/1.1

レスポンス例

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600

{
  "users": [
    {"id": 1, "name": "Alice"},
    {"id": 2, "name": "Bob"}
  ]
}

POST - リソースの作成・処理

新しいリソースの作成や、データの送信・処理に使用します。

特徴

• 安全でない: サーバーの状態を変更する
• 冪等でない: 複数回実行すると複数のリソースが作成される
• キャッシュ不可: 基本的にキャッシュされない
• リクエストボディ: あり

使用例

# 新しいユーザーを作成
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Charlie",
  "email": "charlie@example.com"
}

レスポンス例

HTTP/1.1 201 Created
Location: /api/users/456
Content-Type: application/json

{
  "id": 456,
  "name": "Charlie",
  "email": "charlie@example.com",
  "created_at": "2026-05-02T10:00:00Z"
}

POSTの多様な用途

PUT - リソースの置き換え

既存のリソース全体を更新（置き換え）する際に使用します。

特徴

• 安全でない: サーバーの状態を変更する
• 冪等: 同じリクエストを複数回実行しても結果は同じ
• 完全置き換え: 指定しなかったフィールドはnullや空になる

使用例

# ユーザー情報を完全に置き換え
PUT /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com",
  "role": "admin"
}

POSTとPUTの違い

PATCH - リソースの部分更新

リソースの一部だけを更新する際に使用します。

特徴

• 安全でない: サーバーの状態を変更する
• 冪等性: 設計次第（冪等になるよう設計すべき）
• 部分更新: 指定したフィールドのみ更新

使用例

# メールアドレスのみ更新
PATCH /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "email": "newemail@example.com"
}

PUTとPATCHの違い

# 元のリソース
{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com",
  "role": "user"
}

# PUT（完全置き換え） - roleが消える
PUT /api/users/123
{
  "name": "Alice",
  "email": "new@example.com"
}
→ {"id": 123, "name": "Alice", "email": "new@example.com", "role": null}

# PATCH（部分更新） - roleは保持される
PATCH /api/users/123
{
  "email": "new@example.com"
}
→ {"id": 123, "name": "Alice", "email": "new@example.com", "role": "user"}

DELETE - リソースの削除

リソースを削除する際に使用します。

特徴

• 安全でない: サーバーの状態を変更する
• 冪等: 同じリクエストを複数回実行しても結果は同じ
• リクエストボディ: 通常は使用しない

使用例

# ユーザーを削除
DELETE /api/users/123 HTTP/1.1
Host: api.example.com

レスポンス例

# 削除成功（コンテンツなし）
HTTP/1.1 204 No Content

# または、削除したリソース情報を返す
HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "User 123 has been deleted",
  "deleted_at": "2026-05-02T10:00:00Z"
}

HEAD - ヘッダーのみ取得

GETと同じだが、レスポンスボディを返さずヘッダーのみ返します。

使用例

# リソースの存在確認やメタデータ取得
HEAD /api/users/123 HTTP/1.1

レスポンス例

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234
Last-Modified: Wed, 01 May 2026 10:00:00 GMT
ETag: "abc123"

（ボディなし）

活用シーン

• ファイルサイズの確認（ダウンロード前）
• リソースの存在確認
• Last-Modifiedの確認（更新チェック）

OPTIONS - 利用可能メソッドの確認

サーバーがサポートするメソッドやCORS設定を確認する際に使用します。

使用例

OPTIONS /api/users HTTP/1.1
Host: api.example.com

レスポンス例

HTTP/1.1 204 No Content
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

実務での使い分けガイド

RESTful APIの基本パターン

迷ったときの判断基準

Q: PUTとPATCH、どちらを使うべき？

• リソース全体を送信できる → PUT
• 一部のフィールドのみ更新 → PATCH

Q: GETでデータを送りたい

• クエリパラメータが適切（URL長制限に注意）
• 複雑なデータ → POST（検索APIなど）

Q: DELETEにボディを含めてもいい？

• 仕様上は可能だが、推奨されない
• クエリパラメータで条件指定が一般的

まとめ

HTTPメソッドはリソース指向の設計において、操作の意図を明確に表現します。冪等性と安全性を理解し、適切なメソッドを選択することが、堅牢なAPI設計の基礎です。

関連記事

• HTTPの基本 - リクエストとレスポンスの構造
• HTTPステータスコード - 1xx〜5xxの意味と使い分け
• HTTPヘッダー入門 - リクエスト/レスポンスヘッダーの全体像

参考リソース

• MDN - HTTP request methods
• RFC 9110 - HTTP Semantics (Methods)
• RESTful API Design - HTTP Methods
• IANA - HTTP Method Registry