HTTPステータスコードリファレンス

HTTPステータスコードリファレンスは、HTTP仕様で定義されているすべてのステータスコード（100 Continue から 511 Network Authentication Required まで）を完全に網羅した検索可能なインデックスです。各エントリーには、標準的な名称、それを定義する RFC、コードが実際に意味する内容、送信すべき場面、送信すべきでない場面、および実際のコードベースで陥りがちな一般的な落とし穴が表示されます。ライブフィルターとカテゴリチップを使用すると、ワンクリックでクラス間を移動できます。

単なるフラットなチートシートとは異なり、このツールは各コードに固有のマイクロページを提供し、3つの色分けされたパネル（使用すべき場面 / 使用すべきでない場面 / 落とし穴）と、Express.js、Django、FastAPI、および Go net/http 用の貼り付け可能なハンドラーを用意しています。アニメーション化された通信図は、クライアントからサーバーへのリクエストの移動と、選択されたステータスが返ってくる様子を示しており、ステータスコードが実際に通信上で何を表現しているかを学ぶ初心者に役立ちます。

なぜステータスコードのリファレンスが重要なのか

HTTPステータスコードリファレンスの使い方

1. クイック検索。 上部の検索ボックスにコード（404）または名前の一部（teapot、gateway）を入力して送信します。一致するエントリーが詳細パネルとともに開きます。
2. クラス別に閲覧。 5つのチップ（1xx、2xx、3xx、4xx、5xx）のいずれかをクリックして、グリッドをそのクラスにフィルターします。すべてをクリックするとリセットされます。
3. ライブフィルター。 グリッド의 바로 上にあるフィルターボックスに入力すると、入力に合わせてカードが絞り込まれます。too many や precondition のように名前の半分しか覚えていない場合に便利です。
4. コードを調べる。 任意のカードをクリックして詳細パネルを開きます。意味、使用すべき場面、使用すべきでない場面、一般的な落とし穴、および4つのフレームワークのスニペットブロックが表示されます。
5. スニペットをコピーする。 タブ切り替えと小さなコピーボタンを使用して、貼り付け可能なハンドラーを取得します。
6. 近隣のコードを比較する。 詳細パネルの最後には、同じクラス（1xx / 2xx / 3xx / 4xx / 5xx）の兄弟カードが表示され、素早く並べて比較できます。

5つのHTTPステータスクラスの一覧

よく混同される組み合わせ

• 401対403。 401は未認証を意味し、リクエストに有効な資格情報が不足しています。403は認証済みだが許可されていないことを意味し、資格情報は問題ありませんがユーザーに権限が不足しています。
• 404対410。 404は不明を意味します（どこかに存在するかもしれないし、タイポかもしれません）。410は意図的な削除を意味し、検索エンジンはインデックスからそれを削除する必要があります。
• 301対302対307対308。 301 / 308は恒久的（308はメソッドとボディを厳密に保持）、302 / 307は一時的（307はメソッドとボディを厳密に保持）です。POST / PUT / PATCH のリダイレクトには 307 / 308 を使用してください。
• 400対422。 400はリクエストボディの形式が不正（無効な JSON、フィールドの不足）であることを意味します。422はボディは正常にパースされたものの、値がビジネスルールに違反している（無効なメール形式、数量が範囲外など）ことを意味します。
• 502対503対504。 502はアップストリームが不正なデータを送信したことを意味します。503はサーバーが過負荷またはメンテナンス中であることを意味します。504はアップストリームが時間内に応答しなかったことを意味します。
• 409対412。 409はリソースの現在の状態との競合です。412は特に、前提条件ヘッダー（If-Match、If-Unmodified-Since）が偽（false）と評価されたことを意味します。

特定のステータスコードとペアになるヘッダー

• 201 Created — 新しいリソースを指す Location を含める必要があります。
• 301 / 302 / 307 / 308 — ターゲットの URL を含む Location を含める必要があります。
• 304 Not Modified — 200で表示されるはずだったヘッダー（ETag、Cache-Control、Vary）をエコーバックする必要があります。
• 401 Unauthorized — 受け入れ可能なスキーム（Basic、Bearer）をリストした WWW-Authenticate を含める必要があります。
• 405 Method Not Allowed — 許可されているメソッドをリストした Allow を含める必要があります。
• 413 / 429 / 503 — クライアントが正しくバックオフできるように、多くの場合 Retry-After（秒数または HTTP 日付）を含めます。
• 416 Range Not Satisfiable — Content-Range: bytes */<length> を含める必要があります。

ほとんどの場合無視できるステータスコード

いくつかのコードは技術的には有効ですが、現代の API では非常にまれです：305 Use Proxy（非推奨）、306（予約済み、未使用）、305、506 Variant Also Negotiates, 510 Not Extended、および 508 Loop Detected。ほとんどは歴史的な理由でレジストリに保持されています。ライブラリやミドルウェアがこれらのいずれかを出力する場合は、特別に処理するためのヒントではなく、ライブラリに対するバグ報告として扱ってください。

FAQ

このツールには RFC 9110 以外の RFC のコードも含まれていますか？

はい。RFC 9110（HTTP セマンティクス）、RFC 6585（追加の 4xx / 5xx）、RFC 4918（WebDAV）、RFC 5842（WebDAV バインディング）、RFC 7725（451）、RFC 8297（103 Early Hints）、RFC 8470（425 Too Early）、そして有名な遊び心のある RFC 2324（418 Teapot）をカバーしています。

これらのコードは HTTP/2 および HTTP/3 でも有効ですか？

はい。ステータスコードのセマンティクスは、バージョンに依存しない HTTP セマンティクス文書である RFC 9110 で定義されています。HTTP/2（RFC 9113）および HTTP/3（RFC 9114）は、フレーミングとトランスポートのみを変更します。

特定のコードに直接リンクすることはできますか？

単一のコード（例：404）を入力してフォームを送信すると、フォームの下に詳細パネルが読み込まれます。URL には検索内容が表示され、共有しても安全です。その URL を開くと同じ結果が読み込まれます。

なぜ私のフレームワークでは 418 を返せないのですか？

一部の HTTP ライブラリの古いバージョンでは、内部レジストリにないコードの出力を拒否します。修正するには、ライブラリをアップグレードするか、可能な場合はステータスラインを手動で記述します。

API がエラーボディを伴って 200 を返すことはありますか？

いいえ。監視、リトライ、および仲介者（プロキシなど）はすべて、2xx が成功を意味すると想定しています。エラー構造を返す必要がある場合は、適切な 4xx または 5xx を返し、構造化された詳細をボディ内に入れます。HTTP API 用の問題詳細（Problem Details for HTTP APIs）形式（RFC 9457）が良いテンプレートです。

HTTP ステータスコードの権威あるレジストリはありますか？

はい。IANA は iana.org/assignments/http-status-codes でレジストリを維持しています。このツールは、そのレジストリおよび最も一般的に引用される RFC と同期を保っています。