リクエストの続行を許可。クライアントがヘッダーだけ送って Expect: 100-continue ヘッダーで本文送信OKを確認する仕組み。
HTTP Status Code Reference
HTTP ステータスコードの意味、よくある用途、注意点を検索できます。API設計や障害調査に便利です。
📟 HTTP Status Code Reference
全 HTTP ステータスコード(100-599)の意味・用途を日本語で網羅。「404 ってなんだっけ」が即解決します。
1xx Informational(情報) (4)
サーバーがプロトコル切替に同意。
典型例: WebSocket への昇格時(Upgrade: websocket)
WebDAV: リクエスト処理中(タイムアウト防止)。
本レスポンス前にヒント(Link ヘッダー等)を先送り。
典型例: preload で初期表示高速化
2xx Success(成功) (7)
成功。汎用的な成功レスポンス。
リソースを新規作成した。
典型例: POST 後、Location ヘッダーで作成先 URL を返すのが定番
受理したが処理は非同期で実行中。
プロキシが書き換えた情報を返している。
成功したがレスポンス本文なし。
典型例: DELETE 成功時、PUT で更新成功時
ブラウザにフォームリセットを指示(あまり使われない)。
Range リクエストへの部分応答。
典型例: 動画のシーク、レジューム可能ダウンロード
3xx Redirection(リダイレクト) (7)
複数の選択肢あり(実装稀)。
永続的にリダイレクト。検索エンジンは新URLでインデックスし直す。
典型例: ドメイン引越、HTTPS化、URL正規化
一時的リダイレクト。元URLは引き続き有効扱い。
別URLを GET で見るよう指示。
典型例: POST 後の Redirect-After-POST パターン
条件付きGETでキャッシュ有効。
典型例: If-Modified-Since / If-None-Match 付きリクエストへ
302 と似るが、HTTPメソッドを保持する。
301 と似るが、HTTPメソッドを保持する。
4xx Client Error(クライアントエラー) (28)
リクエストが構文的に不正。
典型例: JSON パース失敗、必須パラメータ欠落
認証が必要・認証失敗。WWW-Authenticate ヘッダーで認証方式を指示。
典型例: ログインしていない、トークン期限切れ
実用は限定的(一部の有料APIで利用)。
認証は通っているがアクセス権限なし。
典型例: 他人のリソースへのアクセス、管理者専用機能
リソースが存在しない。
典型例: URL の打ち間違い、削除済みリソース
そのリソースに対するそのHTTPメソッドは許可されていない。
典型例: GET 専用エンドポイントへの POST
Accept ヘッダーで指定された形式で返せない。
プロキシ認証が必要。
サーバー側のリクエスト受信待ちタイムアウト。
リソース状態の競合。
典型例: 楽観ロック、重複作成、Git の競合等
永続的に削除された(404 の強化版)。
Content-Length が必要。
If-Match 等の前提条件不一致。
リクエスト本文が大きすぎる。
典型例: ファイルアップロードのサイズ制限超過
URL が長すぎる(多くは GET の query が膨大)。
Content-Type が対応外。
Range リクエストの範囲がリソースサイズ外。
Expect ヘッダーの要求を満たせない。
ジョーク用ステータス(RFC 2324、エイプリルフール由来)。
サーバーがそのリクエストを処理できない。
典型例: HTTP/2 の接続再利用で Host が違うサーバーに来た時等
構文は正しいがバリデーションNG。
典型例: Rails / WebDAV 等で多用、フォームバリデーションエラー
WebDAV: ロック中。
リプレイ攻撃のリスクがあるため拒否。
クライアントは別プロトコルへの昇格が必要。
条件付きリクエスト必須(lost update防止)。
レート制限超過。
典型例: Retry-After ヘッダーで待機時間を指示
ヘッダーが大きすぎる。
法的理由で提供不可(GDPR、検閲等)。
5xx Server Error(サーバーエラー) (11)
サーバー内部エラー(汎用)。
典型例: 想定外の例外、null pointer 等
そのHTTPメソッドが未実装。
ゲートウェイ(プロキシ・LB等)が上流から不正な応答を受け取った。
典型例: アプリサーバーが落ちている、LBから見えない
サーバーが一時的に利用不可。
典型例: メンテナンス、過負荷、Retry-After推奨
ゲートウェイが上流からの応答を待ってタイムアウト。
典型例: アプリの処理が遅すぎる、LBタイムアウト
そのHTTPバージョンに非対応。
コンテンツネゴシエーションの設定不正。
WebDAV: ストレージ不足。
WebDAV: 無限ループ検出。
拡張要件を満たしていない。
ネットワーク認証が必要。
典型例: 公衆Wi-Fiのキャプティブポータル
💡 HTTP ステータスコードについて
- 1xx: 情報 / 2xx: 成功 / 3xx: リダイレクト / 4xx: クライアントエラー / 5xx: サーバーエラー
- API設計時のおすすめ: 200/201/204、400/401/403/404/409/422/429、500/503 を中心に使う
- 4xx と 5xx の責任分界: 4xx = クライアント側のミス(直してもらえば直る)、5xx = サーバー側のミス(こちらで修正必要)
- 418 I'm a teapot はジョーク(RFC 2324)。一部の API がレート制限の代替で実用しているケースもあります
📖 関連する解説記事
- HTTPセキュリティヘッダー詳解· 約 8 分 · Security
- HTTP/1.1、HTTP/2、HTTP/3 の違い· 約 7 分 · Network
次に使うツール
作業の流れに近いツールへすぐ移動できます。
HTTPステータスコードの意味を検索する
HTTP Status Code Reference は、HTTPステータスコードの意味、用途、注意点を検索できるリファレンスです。API設計、障害調査、ログ確認、レスポンス仕様のレビューに使えます。
検索や表示はブラウザ内で完結し、入力した検索語はサーバーへ送信されません。
API設計で使い分ける
200、201、204、400、401、403、404、409、422、500などは似ていても意味が異なります。状況に合うコードを選ぶことで、クライアント側の実装や障害調査がしやすくなります。
障害調査を速くする
ログに出ているステータスコードを検索し、原因の方向性を素早く確認できます。認証、権限、入力値、サーバーエラーの切り分けに役立ちます。
HTTP Status Code Reference でできること
- HTTPステータスコードを検索
- 意味、用途、注意点を確認
- API設計や障害調査に便利