HTTP ステータスコード辞典

構文エラーなどでサーバーがリクエストを解釈できない。

💡 JSON パース失敗、必須パラメータ不足。

認証が必要、または認証情報が無効。

💡 実体は「未認証」。WWW-Authenticate ヘッダで認証方式を返すのが慣例。

認証はされているが権限が無い。

💡 管理画面に一般ユーザーがアクセスしたときなど。

リソースが存在しない、または非公開。

💡 一番有名なエラー。存在の有無を隠したいとき 403 の代わりにも。

URL は存在するがそのメソッドは許可されていない。

💡 読み取り専用 URL に POST したときなど。Allow ヘッダ併用。

Accept ヘッダで指定された形式で応答できない。

💡 JSON 専用 API に Accept: application/xml が来たとき。

クライアントの送信が遅すぎてサーバーが待ちきれない。

リソースの現在の状態と矛盾するリクエスト。

💡 楽観ロックで他者が先に更新していたとき。

リソースが恒久的に削除された。404 と違い「もう戻らない」。

💡 クローラーにインデックス削除を促したいとき。

リクエストボディがサーバーの上限を超えている。

💡 アップロード上限超過。

URL が長すぎる。

💡 巨大なクエリ文字列。POST に変えるべきサイン。

Content-Type が API で対応していない形式。

エイプリルフール RFC (RFC 2324) のジョーク。

💡 「コーヒーは淹れられない」。実運用でも稀にイースターエッグで使う。

構文は正しいが意味的に処理できない（バリデーションエラー）。

💡 FastAPI / Rails 等が入力検証エラーで返す。400 を細分化したいとき便利。

リソースが他者により編集ロックされている (WebDAV)。

リプレイされる可能性のある初期データを処理拒否。

💡 TLS 1.3 0-RTT でリプレイ攻撃を避けたいとき。

現プロトコルでは応答せず、上位プロトコルへ切り替えを要求。

条件付きリクエストでないと処理しない。

💡 失われた更新を防ぐため If-Match を必須にする運用。

レート制限に到達。

💡 Retry-After ヘッダで再試行までの秒数を返すと親切。

ヘッダ全体または個別ヘッダが大きすぎる。

💡 Cookie の肥大化、巨大な Authorization ヘッダ等。

法律・行政命令によりアクセスをブロック。

💡 GDPR / 著作権削除要請に基づく削除など。