200 OK と 201 Created と 204 No Content
「とりあえず全部うまくいった」を表す定番のレスポンス。ボディあり。
リクエストの結果として新しいリソースが作成された場合に返す。たいていはPOSTの後。
成功したがボディなし。DELETEや、戻り値が不要なPUTの後によく使う。
3つとも成功系のコードですが、レスポンスに何を載せるかが違います。201は新しく作ったリソースを指すLocationヘッダを付けるべきで、204は定義上ボディが空です。
すべてのHTTPステータスコードを検索でき、わかりやすく解説。
最終更新
リクエストの先頭部分を受信。クライアントは本文の送信を続けてください。
サーバーがプロトコル切り替えに同意(例: HTTP/1.1 から WebSocket)。
WebDAV — リクエストは受理されましたが、まだ完了していません。
Link ヘッダーと共に使用し、最終応答の前にクライアントがリソースをプリロードできるようにします。
リクエスト成功。正確な意味はメソッドに依存します。
リクエスト成功。新しいリソースが作成されました。
リクエストは処理のため受理されましたが、まだ完了していません(非同期処理)。
返されたメタデータは変換プロキシ由来であり、オリジンサーバーからのものではありません。
リクエスト成功。返却する本文はありません。
リクエストを送信したドキュメント表示をリセットするようクライアントに指示(例: フォームをクリア)。
Range リクエストへの応答に使用 — 本文には要求されたバイト範囲のみが含まれます。
リソースに複数の表現があります。クライアントが選択する必要があります。
リソースの恒久的な新URL。検索エンジンはインデックスを更新します。
リソースは一時的に別のURLにあります。メソッドを保持する必要がある場合は 307 を使用。
POST後、結果を GET で取得するようクライアントをリダイレクト(Post/Redirect/Get)。
キャッシュされたコピーがまだ有効 — 条件付き GET(ETag / If-Modified-Since)への応答として送信。
302 と同様だが、リダイレクトに従う際にリクエストメソッドを変更してはなりません。
301 と同様だが、リダイレクトに従う際にリクエストメソッドを変更してはなりません。
クライアントのエラー(構文不正、不正なフレーミング)により、サーバーがリクエストを処理できないか拒否します。
認証が必要で、失敗したか提供されていません。(名前に反して、認可ではなく認証についてです。)
将来の使用のために予約。API が有料クォータ超過を示すために使うことがあります。
サーバーはリクエストを理解しましたが、認可を拒否します。再認証しても解決しません。
サーバーが要求されたリソースを見つけられません。
リクエストメソッドはサーバーに知られていますが、対象リソースでサポートされていません。
クライアントが送信した Accept ヘッダーに一致する応答をサーバーが生成できません。
401 と同様ですが、プロキシのための認証が必要です。
サーバーがリクエストを待機中にタイムアウトしました。
リクエストが対象リソースの現在の状態と競合します(例: バージョン競合)。
リソースは完全に削除され、転送先はありません。
サーバーは Content-Length ヘッダーを要求します。
リクエストヘッダーの前提条件(例: If-Match)がサーバーで満たされませんでした。
リクエスト本文がサーバーが処理可能なサイズを超えています。
URI がサーバーが解釈可能な長さを超えています。
リクエスト本文がサーバーまたはリソースがサポートしないメディアタイプを使用しています。
Range ヘッダーがファイル範囲外の部分を要求しています。
RFC 2324 のエイプリルフールジョーク。コーヒーを淹れることを拒否するサーバーが返します。
応答を生成できないサーバーにリクエストが送信されました(例: 不正な HTTP/2 接続)。
リクエストは整形されていますが意味的なエラーがあります(API でバリデーション失敗によく使われます)。
WebDAV — アクセスされているリソースはロックされています。
サーバーは再送される可能性のあるリクエストを処理したくありません。
クライアントはリクエストを完了するために別のプロトコル(例: TLS)にアップグレードする必要があります。
サーバーはリクエストが条件付きであることを要求します(更新の喪失問題を防ぐため)。
クライアントが一定時間内に多すぎるリクエストを送信しました(レート制限)。
ヘッダーフィールド(または全体のヘッダー)が大きすぎるため、サーバーがリクエストを拒否します。
法的理由によりリソースは利用できません(『華氏 451 度』に由来)。
サーバーが予期しない状況に遭遇しました。万能の 5xx エラーです。
サーバーはリクエストメソッドを認識しません。
ゲートウェイとして動作するサーバーが、アップストリームから無効な応答を受信しました。
サーバーがリクエストを処理する準備ができていません — 通常は過負荷またはメンテナンス中です。
ゲートウェイとして動作するサーバーが、アップストリームから時間内に応答を受け取れませんでした。
サーバーはリクエストで使用された HTTP バージョンをサポートしていません。
WebDAV — サーバーがリクエスト完了に必要な表現を保存できません。
WebDAV — サーバーが処理中に無限ループを検出しました。
ネットワークアクセスのためにクライアントは認証が必要です(キャプティブポータル)。
HTTPステータスコードは、サーバーがすべてのレスポンスの先頭で返す3桁の数字で、リクエストの結果を要約するものです。ブラウザ、クライアント、プロキシ、CDNはこの値を見て、キャッシュするか、リダイレクトするか、リトライするか、ユーザーにエラーを表示するかを判断します。
ステータスコードは先頭の数字によって5つのクラスのいずれかに分類されます。1xxは情報、2xxは成功、3xxはリダイレクト、4xxはクライアントエラー、5xxはサーバーエラーです。クラスさえ分かれば、具体的なコードを調べる前でもおおよその意味は掴めます。
ほとんどのアプリで実際に使うのはごく一部のコア(200、201、204、301、302、304、400、401、403、404、409、422、429、500、502、503)に絞られます。それぞれが*何を意味するか*を理解し、401 Unauthorizedと403 Forbidden、301 Moved Permanentlyと302 Foundの違いをきちんと説明できるようになると、バックエンドやAPIの設計力が一段上がります。
4xxはクライアントの落ち度(不正な入力、認証不足、リソース不存在など)。5xxはクライアントが何をしたかに関係なくサーバー側が失敗したことを示す。数字(404、429)でもキーワード(auth、redirect、rate limit)でも入力すれば、該当するコードがその場で絞り込まれます。
クラスのチップ(1xx、2xx、3xx、4xx、5xx)を使えば、検索ではなくざっと眺めたいときに範囲を狭められます。
各エントリには、そのコードが返される場面、典型的なクライアントの挙動、最も多い原因をまとめてあります。
紛らわしい組み合わせ(401と403、301と302など)には関連リンクを張ってあるので、自分のAPIに合うのはどちらかを判断しやすくなっています。
HTTPステータスコードの5つのクラスと、それぞれの意味を一目で把握できる早見表。定義はRFC 9110、登録はIANA HTTP Status Code Registryにあります。
| クラス | 意味 | 代表的なコード |
|---|---|---|
| 1xx Informational | リクエスト受領、処理中 | 100, 101, 103 |
| 2xx Success | リクエストは成功した | 200, 201, 204, 206 |
| 3xx Redirection | 別の場所を見てほしい | 301, 302, 304, 307, 308 |
| 4xx Client error | リクエストに何か問題がある | 400, 401, 403, 404, 409, 422, 429 |
| 5xx Server error | 正しいリクエストなのにサーバーが処理できなかった | 500, 502, 503, 504 |
「とりあえず全部うまくいった」を表す定番のレスポンス。ボディあり。
リクエストの結果として新しいリソースが作成された場合に返す。たいていはPOSTの後。
成功したがボディなし。DELETEや、戻り値が不要なPUTの後によく使う。
3つとも成功系のコードですが、レスポンスに何を載せるかが違います。201は新しく作ったリソースを指すLocationヘッダを付けるべきで、204は定義上ボディが空です。
リソースを本当に移した(リブランド、URL構造の見直しなど)ときは301を使います。A/Bテスト、ログイン後のリダイレクト、メンテナンスページのような短命な転送は302が適切です。
別の認証情報を送れば解決する可能性があるなら401を返します。どんな認証情報を送っても解決しない(このユーザーにはそもそも触らせない)なら403です。
汎用的なサーバーエラー。要は自分のコードが拾い切れなかった例外を投げた状態。
Bad Gateway。手前のプロキシ(CDNやロードバランサー)が上流サーバーに到達できなかった。
Service Unavailable。サーバーは生きているが、過負荷またはメンテナンス中で応答できない。
Gateway Timeout。プロキシが上流には届いたものの、応答が時間内に返ってこなかった。
どれもサーバーエラーですが、デバッグ時に示唆する内容はまったく違います。500はアプリ自身の問題、502と504はネットワーク経路、503はキャパシティの問題を疑うサインです。
200 OKを返しつつボディに{"error": "..."}を詰める。ステータスコードは契約の一部なので、適切なコード(400、404、500)を返してクライアントが分岐できるようにする。401を使う。401は認証用で、権限不足は403。200を返す。本来は201を返し、Locationヘッダで作成先のURLを示すべき。404 Not Foundは、リクエスト自体は理解できたが、そのURLに対応するリソースが存在しないことを示します。原因として多いのはパスの間違い、リソースの削除、URLのタイプミスなどです。401 Unauthorizedは未認証、つまりサーバーがあなたを誰だか把握していない状態。403 Forbiddenは認証は済んでいるが、そのリソースへの権限がない状態です。401は別の認証情報を送れば解決する可能性がありますが、403は何を送っても解決しません。301 Moved Permanentlyは恒久的なリダイレクトで、ブラウザや検索エンジンは記録を更新します。302 Foundは一時的なリダイレクトで、クライアントは元のURLにアクセスし続けます。恒久移転には301、一時的な迂回には302を使います。500 Internal Server Errorはサーバー側の汎用エラーで、捕捉されなかった例外がそのまま外まで漏れたときによく出ます。クライアントに非はなく、正しいリクエストなのにサーバー側が処理に失敗した状態です。200 OKを返したり、すべての異常を500にまとめてしまうとAPIは扱いにくくなります。最も的確なコードを選びましょう。クライアント、プロキシ、監視ツール、リトライロジックはすべてステータスコードで挙動を分岐させます。429 Too Many Requestsは、クライアントがレート制限に引っかかったときに返すコードです。レスポンスにはRetry-Afterヘッダを含めて、いつ再試行して良いかをクライアントに伝えるのが望ましいです。