HTTPメソッド詳解：GET, POST, PUT, DELETE およびその他のメソッド (2026年版)

HTTPメソッド解説：GET, POST, PUT, DELETEなど（2026年版）

HTTPメソッド（HTTP動詞とも呼ばれます）は、リソースに対して実行したいアクションを定義します。すべてのAPIリクエストはHTTPメソッドを使用しており、適切に選択することは、正確で安全、かつ標準に準拠したWeb APIを構築するために不可欠です。

このガイドでは、9つの標準HTTPメソッドすべて、それぞれの使用場面、およびAPIの構築と利用に関する実践的なコード例を解説します。

クイックリファレンス表

メソッド	目的	リクエストボディ	レスポンスボディ	安全	べき等	キャッシュ可
GET	リソースの取得	なし	あり	はい	はい	はい
POST	リソースの作成	あり	あり	いいえ	いいえ	いいえ
PUT	リソースの置換	あり	任意	いいえ	はい	いいえ
PATCH	部分更新	あり	あり	いいえ	いいえ	いいえ
DELETE	リソースの削除	任意	任意	いいえ	はい	いいえ
HEAD	ヘッダーのみ取得	なし	なし	はい	はい	はい
OPTIONS	許可メソッドの取得	なし	あり	はい	はい	いいえ
TRACE	リクエストのループバック	なし	あり	はい	はい	いいえ
CONNECT	トンネルの確立	なし	なし	いいえ	いいえ	いいえ

主要用語

• 安全 (Safe): リソースを変更しません。副作用なしで呼び出すことができます。
• べき等 (Idempotent): 同じリクエストを複数回呼び出しても、1回呼び出した時と同じ結果になります。
• キャッシュ可能 (Cacheable): レスポンスをブラウザやCDNで保存し、再利用できます。

GET

GETメソッドはリソースを取得します。最も一般的なHTTPメソッドであり、Webページを開いたり、APIデータを取得したり、画像を読み込んだりする際に毎回使用されます。

ルール

• リクエストボディを持ってはなりません（技術的には可能ですが、RFC 9110では非推奨です）。
• サーバーの状態を変更してはなりません。
• べき等かつ安全である必要があります。
• レスポンスはキャッシュ可能です。

例

# ユーザー一覧を取得
curl -X GET https://api.example.com/users

# 特定のユーザーを取得
curl -X GET https://api.example.com/users/42

# クエリパラメータを使用
curl -X GET "https://api.example.com/users?page=2&limit=10"

// JavaScript Fetch API
const response = await fetch('https://api.example.com/users/42');
const user = await response.json();

# Python Requests
import requests
response = requests.get('https://api.example.com/users/42')
user = response.json()

一般的なレスポンスコード

コード	意味
200 OK	リソースの取得に成功
304 Not Modified	キャッシュバージョンがまだ有効
404 Not Found	リソースが存在しない

POST

POSTメソッドは、新しいリソースを作成するか、サーバー側のアクションをトリガーします。最も柔軟なHTTPメソッドであり、単純なデータ取得以外のこと全般に使用されます。

ルール

• 作成するデータを含むリクエストボディを持ちます。
• べき等ではありません。POSTを2回呼び出すと、リソースが2つ作成されます。
• 安全ではありません。サーバーの状態を変更します。
• サーバーは通常、作成されたリソースとともに201ステータスを返します。

例

# 新規ユーザーの作成
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "alice@example.com"}'

const response = await fetch('https://api.example.com/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Alice', email: 'alice@example.com' }),
});
const newUser = await response.json();

response = requests.post(
    'https://api.example.com/users',
    json={'name': 'Alice', 'email': 'alice@example.com'}
)
new_user = response.json()

一般的なレスポンスコード

コード	意味
201 Created	リソースの作成に成功
400 Bad Request	リクエストボディのデータが不正
409 Conflict	リソースが既に存在（例：メールアドレスの重複）
422 Unprocessable Entity	構文は正しいが、セマンティックなエラーがある

PUT

PUTメソッドは、リソース全体を提供されたデータで置き換えます。リソースが存在しない場合、一部のAPIでは新規作成します（アップサート動作）。

ルール

• リクエストボディにリソースの完全なデータが必要です。
• べき等です。同じデータでPUTを複数回呼び出しても、結果は同じです。
• 特定のフィールドだけでなく、リソース全体を置き換えます。

PUT と PATCH の違い

これはAPI設計において最も混同されやすい点の一つです。

項目	PUT	PATCH
送信するもの	リソース完全体	変更されたフィールドのみ
不足しているフィールド	null/デフォルト値に設定	変更されず維持
べき等性	はい	必ずしもそうとは限らない
ユースケース	完全な置換	部分的な更新

例

# ユーザーを完全に置き換える
curl -X PUT https://api.example.com/users/42 \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice Updated", "email": "alice@new.com", "age": 30}'

const response = await fetch('https://api.example.com/users/42', {
  method: 'PUT',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: 'Alice Updated',
    email: 'alice@new.com',
    age: 30
  }),
});

response = requests.put(
    'https://api.example.com/users/42',
    json={'name': 'Alice Updated', 'email': 'alice@new.com', 'age': 30}
)

一般的なレスポンスコード

コード	意味
200 OK	リソースの置換に成功
201 Created	リソースが存在しなかったため、新規作成
204 No Content	置換に成功したが、レスポンスボディなし
404 Not Found	リソースが存在しない（アップサート非対応の場合）

PATCH

PATCHメソッドは、リソースに対して部分的な修正を適用します。変更したいフィールドのみを送信し、それ以外は元のままの状態が維持されます。

ルール

• 修正されるフィールドのみを含みます。
• 必ずしもべき等ではありません（実装に依存します）。
• PUTに比べて、小さな変更に対して帯域幅の効率が良くなります。

例

# ユーザーのメールアドレスのみを更新
curl -X PATCH https://api.example.com/users/42 \
  -H "Content-Type: application/json" \
  -d '{"email": "alice@new.com"}'

const response = await fetch('https://api.example.com/users/42', {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email: 'alice@new.com' }),
});

response = requests.patch(
    'https://api.example.com/users/42',
    json={'email': 'alice@new.com'}
)

JSON Patch 形式

一部のAPIでは、プレーンなJSONボディの代わりに正式な JSON Patch 形式 (RFC 6902) を使用します。

curl -X PATCH https://api.example.com/users/42 \
  -H "Content-Type: application/json-patch+json" \
  -d '[
    {"op": "replace", "path": "/email", "value": "alice@new.com"},
    {"op": "add", "path": "/phone", "value": "+1234567890"}
  ]'

DELETE

DELETEメソッドは、サーバーからリソースを削除します。

ルール

• べき等です。既に削除されたリソースを削除しようとしてもエラーになるべきではなく、204 または 404 を返すべきです。
• リクエストボディを持つ場合と持たない場合があります（ほとんどのAPIでは使用しません）。
• 削除に成功した場合は、通常 204 No Content を返します。

例

# ユーザーを削除
curl -X DELETE https://api.example.com/users/42

const response = await fetch('https://api.example.com/users/42', {
  method: 'DELETE',
});

response = requests.delete('https://api.example.com/users/42')

一般的なレスポンスコード

コード	意味
200 OK	削除成功。レスポンスボディに削除されたリソースが含まれる
204 No Content	削除成功。レスポンスボディなし
404 Not Found	リソースが存在しない
409 Conflict	削除不能（例：依存するリソースがある）

HEAD

HEADメソッドはGETと同一ですが、レスポンスボディを含まずヘッダーのみを返します。フルコンテンツをダウンロードせずに、リソースが存在するか、サイズはどのくらいか、最終更新日はいつかを確認するために使用されます。

例

# ファイルが存在するか確認し、そのサイズを取得
curl -I https://example.com/large-file.zip

レスポンス:

HTTP/2 200
Content-Type: application/zip
Content-Length: 524288000
Last-Modified: Mon, 03 Feb 2026 10:00:00 GMT

ユースケース

• ダウンロード前にリソースの存在を確認する
• Content-Length を取得してダウンロード時間を推定する
• キャッシュ検証のために Last-Modified や ETag を確認する
• ダウンロードせずに URL リダイレクトを確認する

OPTIONS

OPTIONSメソッドは、サーバーがある特定のURLに対してサポートしているHTTPメソッドを返します。CORSのプリフライトリクエストで最もよく見られます。

例

curl -X OPTIONS https://api.example.com/users -i

レスポンス:

HTTP/2 204
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

CORS プリフライト

ブラウザは特定のクロスオリジンリクエストを実行する前に、自動的にOPTIONSリクエストを送信します。これをプリフライトリクエストと呼びます。

ブラウザ -> OPTIONS /api/users (プリフライト)
サーバー <- 204 (CORSヘッダー付き)
ブラウザ -> POST /api/users (実際のリクエスト)
サーバー <- 201 Created

TRACE

TRACEメソッドは、受信したリクエストをクライアントにそのまま送り返します。中間のプロキシがリクエストに対してどのような変更を加えているかを確認するためのデバッグに使用されます。

curl -X TRACE https://example.com

TRACEは通常、セキュリティ上の理由（攻撃者にクッキーなどのヘッダーを公開してしまう可能性があるため）から、本番環境のサーバーでは無効化されています。

CONNECT

CONNECTメソッドは、サーバーへのトンネル（通常はHTTPプロキシを経由したHTTPS通信）を確立します。アプリケーションコードから直接使用することはほとんどありません。

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com

HTTPメソッドを用いたRESTful APIの設計

以下に、HTTPメソッドが標準的な CRUD 操作にどのようにマッピングされるかを示します。

操作	HTTP メソッド	エンドポイント	例
全件取得	GET	/users	全ユーザーを取得
1件取得	GET	/users/:id	ユーザー 42 を取得
作成	POST	/users	新規ユーザーを作成
置換	PUT	/users/:id	ユーザー 42 を置換
更新	PATCH	/users/:id	ユーザー 42 のメールを更新
削除	DELETE	/users/:id	ユーザー 42 を削除

Express.js の例

const express = require('express');
const app = express();
app.use(express.json());

// GET /users - ユーザー一覧
app.get('/users', (req, res) => {
  res.json(users);
});

// GET /users/:id - ユーザーを1件取得
app.get('/users/:id', (req, res) => {
  const user = users.find(u => u.id === req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

// POST /users - ユーザーの作成
app.post('/users', (req, res) => {
  const user = { id: generateId(), ...req.body };
  users.push(user);
  res.status(201).json(user);
});

// PUT /users/:id - ユーザーの置換
app.put('/users/:id', (req, res) => {
  const index = users.findIndex(u => u.id === req.params.id);
  if (index === -1) return res.status(404).json({ error: 'Not found' });
  users[index] = { id: req.params.id, ...req.body };
  res.json(users[index]);
});

// PATCH /users/:id - 部分更新
app.patch('/users/:id', (req, res) => {
  const user = users.find(u => u.id === req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  Object.assign(user, req.body);
  res.json(user);
});

// DELETE /users/:id - ユーザーの削除
app.delete('/users/:id', (req, res) => {
  const index = users.findIndex(u => u.id === req.params.id);
  if (index === -1) return res.status(404).json({ error: 'Not found' });
  users.splice(index, 1);
  res.status(204).send();
});

よくある間違い

データを変更する操作にGETを使用する: GETはサーバーの状態を変更してはなりません。メールの送信、決済の処理、ワークフローのトリガーなどのアクションには POST を使用してください。

すべてにPOSTを使用する: POSTはあらゆる操作に使用できますが、正しいメソッドを使用することでAPIは予測可能になり、自己文書化されます。

PATCHのつもりでPUTを使用する: 1つのフィールドのみを更新する場合は PATCH を使用してください。PUT はリソース全体を置き換えるべきものです。

適切なステータスコードを返さない: POSTに対しては 201 (200ではなく)、DELETEに対しては 204 (200ではなく)、リソースが見つからない場合は 404 (エラーメッセージ付きの200ではなく) を返すようにしてください。

まとめ

HTTPメソッドは、すべてのWeb APIの基礎です。これらを正しく使用することで、APIは予測可能、キャッシュ可能、そして標準に準拠したものになります。読み取りには GET、作成には POST、置換には PUT、更新には PATCH、削除には DELETE。これら5つをマスターすれば、API設計のニーズの99%をカバーできます。

APIを通じてAI生成メディア（画像、動画、音声、トーキングアバターなど）を利用するアプリケーションを構築している場合は、標準的なHTTPメソッドとクリーンなレスポンス形式を備えた統合REST APIを提供する Hypereal AI をチェックしてみてください。

Hypereal AI を無料で試す -- 35クレジット、クレジットカード不要。