200 OK と 201 Created と 204 No Content
「とりあえず全部うまくいった」を表す定番のレスポンス。ボディあり。
リクエストの結果として新しいリソースが作成された場合に返す。たいていはPOSTの後。
成功したがボディなし。DELETEや、戻り値が不要なPUTの後によく使う。
3つとも成功系のコードですが、レスポンスに何を載せるかが違います。201は新しく作ったリソースを指すLocationヘッダを付けるべきで、204は定義上ボディが空です。
すべてのHTTPステータスコードを検索でき、わかりやすく解説。
最終更新
Coddy teaches you by writing real code in your browser - interactive lessons, instant feedback, and AI help when you get stuck.
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ヘッダを含めて、いつ再試行して良いかをクライアントに伝えるのが望ましいです。