概要

HTTPを実務で使ううえで、メソッドとステータスコードは最重要の基本要素です。どの操作をしたいのか、結果が成功か失敗かを正しく表現できるようになると、API設計と不具合調査の精度が上がります。

• 想定読者: Web開発初学者、API利用者、APIを設計・実装するエンジニア
• 前提知識: HTTPの全体像、リクエスト/レスポンスの構造
• 想定読了時間: 6〜9分

メソッドとステータスコードの役割

HTTPメソッドは「何をしたいか」を表し、ステータスコードは「どうなったか」を表します。この2つを分けて理解すると、通信の意味を短時間で読めるようになります。

HTTP通信では、クライアントはメソッドで操作の意図を示し、サーバーはステータスコードで処理結果を返します。

• メソッドの例: 取得したい、作成したい、更新したい、削除したい
• ステータスコードの例: 成功した、入力が不正だった、認証が必要だった、対象が見つからなかった、サーバー側で失敗した

この対応が曖昧だと、API設計もデバッグもぶれやすくなります。

よく使うHTTPメソッド

最初に押さえるべきHTTPメソッドは、GET、POST、PUT、PATCH、DELETEです。特にGETとPOSTだけで終わらず、更新系の違いも早めに整理すると実務で役立ちます。

GET

GETはリソースを取得するためのメソッドです。基本的には副作用を持たせず、同じ条件なら同じ結果を返すことが期待されます。

GETは最もよく使うメソッドです。Webページ表示、一覧取得、詳細取得などで使われます。

GET /products/1 HTTP/1.1
Host: api.example.com
Accept: application/json

よくある用途: 一覧取得、詳細取得、検索、ページネーション付き取得

注意点として、GETでデータ更新を行ったり、サーバー状態を変える操作を含めたりするのは避けましょう。またキャッシュ対象になりうることも意識が必要です。

POST

POSTは新規作成や、単純な取得では表しにくい処理実行に使われます。入力データを本文で送ることが多いメソッドです。

POST /orders HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "product_id": 10,
  "quantity": 2
}

よくある用途: 新規作成、フォーム送信、ログイン、複雑な検索条件の処理、バッチ実行

なお、何でもPOSTに寄せすぎるとAPIの意味が読みにくくなります。作成成功なら 201 Created を返す設計が自然です。

PUT

PUTは対象リソースを全体として置き換える更新に向くメソッドです。送った内容で丸ごと更新するという前提で設計されることが多いです。

PUT /users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Yamada",
  "email": "yamada@example.com",
  "role": "admin"
}

一部項目だけ送る設計にすると、PATCHとの違いが曖昧になります。未指定項目の扱いをAPI仕様で明確にしておくことが重要です。

PATCH

PATCHはリソースの一部だけを更新したいときに使います。変更したい項目だけ送る設計と相性がよいです。

PATCH /users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Suzuki"
}

部分更新のルールを明示しないと利用者が混乱しやすくなります。null を送る意味や未指定項目の扱いを明確にしておきましょう。

DELETE

DELETEはリソースを削除するためのメソッドです。成功時に本文を返さず 204 No Content を使う設計もよくあります。

DELETE /products/10 HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxxx

物理削除か論理削除かを利用者が理解できるようにし、すでに存在しない対象を削除したときの扱いも決めておくことが重要です。

メソッド選択の考え方

「実装しやすいメソッド」ではなく、「読んだときに意味が伝わるメソッド」を選ぶことが重要です。

よくあるアンチパターン

HTTPメソッドを適切に使わないと、APIが読みにくくなり、キャッシュや監視、権限制御でも不利になります。

避けたい例:

• 何でも POST にする
• 更新処理を GET で行う
• PUT と PATCH の使い分けが曖昧
• URLに動詞を多用する（例: /createUser、/deleteProduct）

必ずしも絶対禁止ではありませんが、REST的な読みやすさや標準的な期待との相性は下がりやすいです。

ステータスコードの基本分類

ステータスコードは3桁の数字で、成功・リダイレクト・クライアントエラー・サーバーエラーを大きく分類できます。まずは1xx〜5xxの意味をざっくり把握するだけでも十分役立ちます。

最初に実務で特に重要なのは、2xx、4xx、5xxです。

よく使う2xx

2xxは成功を表しますが、成功の中にも意味の違いがあります。200だけで済ませず、201や204も使い分けるとAPIの意図が伝わりやすくなります。

200 OK

HTTP/1.1 200 OK
Content-Type: application/json

{"id":1,"name":"Keyboard"}

201 Created

新しいリソースを作成したことを明確に伝えたいときに使います。POSTでの新規作成と相性がよいコードです。

HTTP/1.1 201 Created
Content-Type: application/json
Location: /products/101

{"id":101,"name":"Keyboard"}

204 No Content

成功したが、返す本文がないことを示します。削除や単純更新でよく使われます。

HTTP/1.1 204 No Content

よく使う4xx

4xxは「クライアントからの要求に問題がある」ことを示します。特に400、401、403、404の違いは早めに整理しておくと調査がしやすくなります。

400 と 422 の違い

厳密な使い分けは実装方針によりますが、400は構文や基本条件の不正、422は意味的なバリデーション失敗として整理すると扱いやすいです。

• 400 の例: JSONが壊れている、必須パラメータ自体が欠けている
• 422 の例: メールアドレス形式は正しいが業務ルール違反、価格が負数で登録不可

実務では422を使わず400に寄せるAPIもあります。重要なのは、プロジェクト内で一貫性を持つことです。

401 と 403 の違い

401は「認証されていない」、403は「認証されているが許可されていない」と考えると整理しやすいです。

404 の読み方

404は「そのURLや対象が見つからない」ことを示します。認可都合であえて404を返す設計もあります。

単純な例: /products/9999 に対象が存在しない、URLスペルが間違っている

一方で、存在の有無を秘匿するために、本当は権限不足でも404を返す設計もあります。そのため、仕様とセキュリティ方針をセットで見る必要があります。

よく使う5xx

5xxはサーバー側で正常に処理できなかったことを示します。利用者の入力よりも、アプリケーションやインフラの問題を疑う場面です。

利用者側でまず見るポイント: いつから発生したか、全リクエストで起きるか、特定エンドポイントだけか、アプリログやプロキシログに何が出ているか

メソッドとステータスコードの組み合わせ例

メソッド単体ではなく、「どのメソッドに対してどのステータスコードが返るか」でAPIの意味が完成します。

curlで確認する例

# 取得
curl -i https://api.example.com/products/1

# 作成
curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Keyboard","price":5000}' \
  https://api.example.com/products

# 削除
curl -i \
  -X DELETE \
  https://api.example.com/products/1

出力を見るときは、まず次を確認します。

1. どのメソッドを使ったか
2. 返ってきたステータスコードは何か
3. レスポンスボディにエラー詳細があるか
4. 必要なら Content-Type や Location も見る

よくあるつまずき

メソッドとステータスコードは、仕様だけでなく実装・運用で崩れやすいポイントです。違和感のある設計は後で利用者を混乱させます。

実務での判断のコツ

厳密な正しさだけでなく、「利用者が予測しやすいか」「プロジェクト全体で一貫しているか」を重視すると運用しやすくなります。

• 同じ種類の操作には同じメソッドとステータスコードを使う
• 例外的な扱いを増やしすぎない
• API利用者が名前だけで意図を読めるようにする
• エラー時は利用者が修正可能な情報を返す
• 4xx と 5xx を混ぜない

特に大切なのは、一度決めたルールをシリーズやAPI全体で揃えることです。

まとめ

HTTPメソッドは操作の意図を、ステータスコードは処理結果を表します。GET、POST、PUT、PATCH、DELETEの違いと、2xx、4xx、5xxの意味を押さえるだけで、HTTPの読み書きの精度は大きく上がります。

• メソッドは「何をしたいか」を表す
• ステータスコードは「どうなったか」を表す
• GET は取得、POST は作成や処理実行、PUT は全体更新、PATCH は部分更新、DELETE は削除
• 成功時は 200、201、204 の使い分けが重要
• エラー時は 400、401、403、404、409、422、500 などの意味を区別する
• 実務では厳密さだけでなく、一貫性と予測しやすさも重要