【実務・中級編】HTTPステータスコードの分類(1xx-5xx) – HTTPプロトコル・通信規格実践ガイド

HTTPステータスコード、それはサーバーからの「声なき声」だ！ 〜1xxから5xxまで、現場で役立つ深掘り解説〜

どうも、皆さん。長年ネットワークの最前線でパケットと格闘してきたベテランエンジニアです。Web APIの設計にしても、インフラの運用にしても、避けては通れないのがHTTP。そして、そのHTTP通信の成否を雄弁に物語るのが、あの3桁の数字、ステータスコードですよね。

「200 OK」なら安心、でも「500 Internal Server Error」なんて見ると、心臓がキュッと掴まれる。そんな経験、きっと皆さんにもあるはずです。でも、単に「成功」「失敗」と捉えるだけでは、もったいない！ステータスコードは、サーバーが今どんな状況で、クライアントに何を伝えようとしているのか、その「声なき声」なんです。

今回は、HTTP/0.9からHTTP/1.1にかけて発展してきたこのステータスコードの、特に現場で役立つ分類（1xx〜5xx）に焦点を当て、その役割、通信フロー、そして実際のコード例や設定例を交えながら、深掘りしていきましょう。教科書的な説明に終始するのではなく、数々の現場で得た「生きた」知見を、皆さんの実務に直結する形で解説していきます。

そもそも、ステータスコードって何だっけ？

HTTPステータスコードは、クライアント（ブラウザやAPIクライアント）からのリクエストに対して、サーバーがどのような結果を返したのかを示す3桁の数字です。RFC 2616（HTTP/1.1の主要な仕様を定めたもの）で定義されていますが、その後のRFCで拡張・更新もされています。

この3桁の数字は、実は意味のあるグループに分けられています。それが、今回解説する「1xx〜5xx」という分類です。それぞれの桁の役割、特に最初の桁が、そのコードが属するクラスを示しています。

1xx: 情報レスポンス – 「ちょっと待っててね、処理中だよ」

このクラスのステータスコードは、リクエストが受け取られ、処理が継続中であることを示します。HTTP/1.1で導入されたもので、それ以前のバージョンには存在しませんでした。クライアントはこのコードを受け取っても、まだ最終的なレスポンスは来ていないと理解し、処理を続行します。

  • 100 Continue
  • 概要: クライアントがリクエストボディを送信する前に、サーバーがリクエストヘッダーを受け取り、そのままリクエストを続行しても問題ないことを示します。特に、大きなリクエストボディを送信する際に、事前にサーバー側の状態を確認するために使われます。
  • 通信フロー:

1. クライアントが `Expect: 100-continue` ヘッダーを付けてリクエストを送信。
2. サーバーがリクエストヘッダーをチェックし、問題なければ `100 Continue` を返す。
3. クライアントがリクエストボディを送信。
4. サーバーがリクエスト全体を処理し、最終的なステータスコードを返す。

  • 実務でのポイント: 巨大なファイルをアップロードする際などに、ネットワークの無駄遣いを防ぐために有効です。ただ、全てのサーバーやプロキシがこれを正しくサポートしているわけではないため、注意が必要です。
  • `curl` での例:

# -H でヘッダーを追加し、–data-binary で大きなバイナリデータを送信する例
# 実際には、 Expect: 100-continue ヘッダーが自動的に付与される場合が多い
curl -v -H “Expect: 100-continue” –data-binary “@large_file.dat” https://example.com/upload

`curl` の `-v` オプションで詳細な通信ログを確認すると、`100 Continue` のやり取りが見えることがあります。

2xx: 成功 – 「うん、うまくいったよ！」

このクラスは、リクエストが正常に処理され、クライアントが期待していたアクションが成功したことを示します。Web APIでは最も頻繁に目にすることになるでしょう。

  • 200 OK
  • 概要: リクエストが成功したことを示す最も一般的なコードです。GETリクエストであればリソースが返され、POSTリクエストであればリソースが作成された（あるいは処理された）ことを示します。
  • 通信フロー:

1. クライアントがリクエストを送信。
2. サーバーがリクエストを処理し、成功したと判断。
3. サーバーが `200 OK` と共に、要求されたリソースや処理結果をレスポンスボディに含めて返す。

  • 実務でのポイント: APIのGETエンドポイントが正常にデータを返した場合、POSTエンドポイントがリソースを正常に作成・更新した場合などに使用されます。
  • Python (Requestsライブラリ) での例:

import requests

response = requests.get(‘https://api.example.com/users/1’)

if response.status_code == 200:
print(“ユーザー情報取得成功！”)
print(response.json()) # レスポンスボディをJSONとしてパース
else:
print(f”エラー発生: ステータスコード {response.status_code}”)

  • 201 Created
  • 概要: リクエストが成功し、新しいリソースが作成されたことを示します。通常、POSTリクエストやPUTリクエストで、リソースが新たに生成された場合に返されます。レスポンスヘッダーには、作成されたリソースのURIを示す `Location` ヘッダーが含まれることが期待されます。
  • 実務でのポイント: 新規ユーザー登録や、新しい投稿の作成などで使われます。`Location` ヘッダーは、作成されたリソースにアクセスするための重要な情報源です。
  • Fetch API (JavaScript) での例:

fetch(‘https://api.example.com/users’, {
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json’,
},
body: JSON.stringify({ name: ‘Taro Yamada’, email: ‘taro@example.com’ }),
})
.then(response => {
if (response.status === 201) {
console.log(‘ユーザー作成成功！’);
// Locationヘッダーから作成されたリソースのURLを取得
const newUserUrl = response.headers.get(‘Location’);
console.log(‘作成されたユーザーURL:’, newUserUrl);
return response.json(); // レスポンスボディを取得
} else {
// その他のエラー処理
console.error(‘ユーザー作成失敗:’, response.status);
return response.text().then(text => console.error(‘エラー詳細:’, text));
}
})
.then(data => console.log(‘レスポンスデータ:’, data))
.catch(error => console.error(‘ネットワークエラー:’, error));

  • 204 No Content
  • 概要: リクエストは成功したが、レスポンスボディは含まれていないことを示します。DELETEリクエストでリソースを削除した後や、PUTリクエストでリソースを更新したが、更新後のリソースを返す必要がない場合などに使われます。
  • 実務でのポイント: クライアント側でUIの更新などが必要ない場合に、不要なデータ転送を避けるために使われます。
  • Nginx 設定例 (特定のパスへのリクエストを204で応答させる):

location /health_check {
# ヘルスチェックエンドポイントなどで、単純に成功を返したい場合
# レスポンスボディは空にする
return 204;
}

3xx: リダイレクト – 「あっちに移動してね！」

このクラスは、リクエストされたリソースが別のURIに移動したことを示し、クライアントに新しいURIへアクセスするように促します。

  • 301 Moved Permanently
  • 概要: リソースが恒久的に新しいURLに移動したことを示します。ブラウザは自動的に新しいURLにリダイレクトし、検索エンジンもURLの変更を認識します。
  • 通信フロー:

1. クライアントが古いURLにリクエストを送信。
2. サーバーはリソースが恒久的に移動したと判断。
3. サーバーは `301 Moved Permanently` と共に、新しいURLを `Location` ヘッダーに含めて返す。
4. クライアント（ブラウザ）は `Location` ヘッダーのURLに再度リクエストを送信。

  • 実務でのポイント: ウェブサイトのドメイン変更、URL構造の変更などに伴うSEO対策として重要です。HTTPリクエストメソッド（POSTなど）によっては、リダイレクト先へGETメソッドでアクセスするか、POSTメソッドでアクセスするか（307/308）など、注意が必要です。
  • Apache `.htaccess` 設定例:

# example.com を www.example.com へ恒久的にリダイレクト
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.)$ http://www.example.com/$1 [R=301,L]

  • 302 Found (または 307 Temporary Redirect)
  • 概要: リクエストされたリソースが一時的に別のURLにあることを示します。ブラウザはリダイレクトしますが、元のURLへのリクエストは一時的なものであることを認識します。HTTP/1.1では、HTTPメソッドを変更せずにリダイレクトさせるために `307 Temporary Redirect` が導入されました。`302 Found` は、元のメソッドを保持するとは限りません（ただし、多くの実装では保持されます）。
  • 実務でのポイント: メンテナンス中のページへの一時的な誘導や、A/Bテストなどで使われます。HTTPメソッドの変更を厳密に制御したい場合は `307` を使うのが良いでしょう。
  • Nginx 設定例:

location /maintenance {
# メンテナンス期間中は、このパスへのアクセスを別URLに一時リダイレクト
return 307 /under_maintenance.html;
}

4xx: クライアントエラー – 「君の頼み方が間違ってるよ！」

このクラスは、リクエストに何らかの誤りがあり、サーバーがそれを処理できなかったことを示します。クライアント側で修正が必要な場合が多いです。

  • 400 Bad Request
  • 概要: リクエストの構文が不正であったり、不正なリクエストパラメータが含まれているなど、サーバーがリクエストを理解できなかった場合に返されます。
  • 実務でのポイント: APIの入力バリデーションに失敗した場合や、リクエストヘッダーの形式が不正な場合などに発生します。デバッグ時には、クライアントが送信したリクエスト内容を正確に確認することが重要です。
  • `curl` で不正なJSONを送信する例:

curl -v -X POST -H “Content-Type: application/json” \
-d ‘{“name”: “Alice”, “age”: 30,’ \ # 不正なJSON（閉じカッコがない）
https://api.example.com/users

この場合、サーバーはJSONとしてパースできないため、`400 Bad Request` を返す可能性が高いです。

  • 401 Unauthorized
  • 概要: リクエストされたリソースにアクセスするために、認証が必要であることを示します。通常、`WWW-Authenticate` ヘッダーと共に返され、クライアントに認証情報（ユーザー名/パスワード、APIキー、トークンなど）の提示を求めます。
  • 実務でのポイント: ログインしていないユーザーが保護されたリソースにアクセスしようとした場合や、APIキーが無効・期限切れの場合などに発生します。
  • `curl` で認証なしでリクエストした場合:

curl -v https://api.example.com/protected/resource

サーバーは `401 Unauthorized` と共に `WWW-Authenticate: Basic realm=”Restricted Area”` のようなヘッダーを返すかもしれません。

  • 403 Forbidden
  • 概要: 認証は成功した（あるいは必要なかった）ものの、クライアントにはそのリソースへのアクセス権限がないことを示します。
  • 実務でのポイント: ユーザーはログインしているが、そのユーザーには特定の操作（例: 管理者権限が必要な操作）を実行する権限がない場合などに使われます。`401` との違いは、認証の有無ではなく、許可されているか否かという点です。
  • Python (Requestsライブラリ) での例:

import requests

# 認証済みだが、権限がないリソースへのアクセスを試みる
headers = {‘Authorization’: ‘Bearer your_valid_token’}
response = requests.get(‘https://api.example.com/admin/dashboard’, headers=headers)

if response.status_code == 403:
print(“アクセス権限がありません。管理者に問い合わせてください。”)
else:
print(f”ステータスコード: {response.status_code}”)

  • 404 Not Found
  • 概要: リクエストされたリソースがサーバー上に見つからなかったことを示します。
  • 実務でのポイント: URLのタイプミス、存在しないAPIエンドポイントへのアクセス、削除されたリソースへのアクセスなどで発生します。デバッグ時には、URLが本当に正しいか、リソースが存在するかを確認します。
  • Fetch API (JavaScript) での例:

fetch(‘https://api.example.com/nonexistent/resource’)
.then(response => {
if (response.status === 404) {
console.error(‘指定されたリソースは見つかりませんでした。URLを確認してください。’);
} else {
console.log(‘ステータス:’, response.status);
}
})
.catch(error => console.error(‘ネットワークエラー:’, error));

5xx: サーバーエラー – 「ごめん、僕のせいだ…」

このクラスは、リクエストは有効であったにも関わらず、サーバー側で予期せぬ問題が発生し、リクエストを完了できなかったことを示します。

  • 500 Internal Server Error
  • 概要: サーバー内部で予期せぬエラーが発生し、リクエストを処理できなかったことを示す汎用的なコードです。
  • 実務でのポイント: アプリケーションのバグ、データベース接続エラー、設定ミスなど、原因は多岐にわたります。このエラーが出た場合は、サーバー側のログを詳細に調査することが不可欠です。
  • Nginx ログの例 (エラー発生時):

2023/10/27 10:30:01 [error] 12345#12345: 67890 upstream prematurely closed connection while reading response header from upstream, client: 192.168.1.100, server: example.com, request: “GET /api/data HTTP/1.1”, upstream: “http://127.0.0.1:8000/api/data”, host: “example.com”

このログは、Nginxがバックエンドアプリケーション（upstream）から予期せず接続が閉じられたことを示唆しており、アプリケーション側に問題がある可能性が高いです。

  • 503 Service Unavailable
  • 概要: サーバーが一時的にリクエストを処理できない状態にあることを示します。これは、サーバーの過負荷、メンテナンス、あるいは一時的な障害などが原因である可能性があります。
  • 実務でのポイント: 負荷分散装置（ロードバランサー）などが、バックエンドサーバーが応答しない場合にこのコードを返すことがあります。一時的なものであることを示すため、`Retry-After` ヘッダーで、いつ再試行すべきかの情報を提供することがあります。
  • `curl` で `Retry-After` ヘッダーを確認する例:

curl -v https://example.com/temporarily_unavailable

レスポンスに `Retry-After: 60` のようなヘッダーが含まれていれば、「60秒後に再試行してください」という意味になります。

まとめ：ステータスコードはコミュニケーションツール

ここまで、HTTPステータスコードの1xxから5xxまでを、その意味合い、通信フロー、そして実践的なコード例や設定例を交えて解説してきました。

ステータスコードは、単なる数字ではありません。それは、クライアントとサーバーの間で行われる、非常に重要な「コミュニケーション」です。特に、Web APIを設計する際には、これらのコードを適切に使い分けることで、APIの利用者はサーバーの状態を正確に把握し、適切な対応を取ることができます。

  • 1xx: 処理が進行中であることを伝える。
  • 2xx: 「OKだよ！」と成功を伝える。
  • 3xx: 「あっちに移ってね」と移動を促す。
  • 4xx: 「君の頼み方がおかしいよ」とクライアントに修正を求める。
  • 5xx: 「ごめん、僕（サーバー）の調子が悪かった」とサーバー側の問題を伝える。

これらのコードを正しく理解し、実装に活かすことで、APIの堅牢性や、インフラの運用効率は格段に向上します。皆さんの日々の開発や運用において、この記事が少しでもお役に立てれば幸いです。

これからも、現場のリアルな声をお届けしていきますので、お楽しみに！

スポンサーリンク

コメント

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