HTTP Status Code / APIレスポンスカタログ

代表的な23種類のHTTPステータスコードを検索し,意味,RFC参照,ヘッダーと本文の例を確認できるエラー早見表です.表示例は学習用で,実際のサーバーが返す原因・本文・ヘッダーを断定しません.未収録コードや厳密な定義はIANAの公式登録一覧も参照してください.

読み込み中...

ZeroToolsのブラウザ内処理とプライバシー

ZeroToolsは,入力内容を端末内で処理するツールを中心に提供しています.各ツールの対応範囲と制限を確認して利用してください.

データの取り扱い・プライバシー方針
第1章

ステータスコードを構成する五つのクラス

Webシステム間の通信において,HTTPステータスコードはリクエストの処理結果を三桁の数字で表現する重要な役割を担います.本ツールに収録されている代表的な23コードも,プロトコルの定義に基づき五つのクラスに分類されています.

百番台(1xx)は情報レスポンスと呼ばれ,処理が継続中であることを示します.たとえば「100 Continue」は,クライアントが引き続きリクエスト本文を送信してよいことを伝えます.二百番台(2xx)は成功レスポンスであり,クライアントからの要求がサーバー側で正常に受信・理解・処理されたことを意味します.

一般的な「200 OK」のほか,リソース作成完了を示す「201 Created」などが該当します.

三百番台(3xx)はリダイレクト(転送)を指示するクラスです.要求されたリソースが別のURLへ移動している場合や,キャッシュの利用を促す場合に用いられます.四百番台(4xx)はクライアントエラーを示し,リクエストの構文が間違っている,あるいは認証や権限が不足しているなど,要求元に問題があることを通知します.

そして五百番台(5xx)はサーバーエラーを表し,クライアントの要求は適切だったものの,サーバー側の例外や過負荷などの理由により処理を完了できなかった状態を示します.

これら五つのクラスを正確に把握することは,API連携やフロントエンド開発におけるエラーハンドリングの基礎となります.本ツールのエラー早見表を活用することで,発生した問題がクライアント側とサーバー側のどちらに起因するのかを迅速に切り分けることが可能です.

第2章

代表コードの検索と分類機能の操作方法

本ツールは,開発現場での迅速なトラブル調査を支援するため,直感的な検索と分類機能を備えたHTTPステータスコードの詳細解説リファレンスとして機能します.画面上部の「カタログ検索」エリアには,検索窓と六つのタブ(ALL,1xx 情報,2xx 成功,3xx 転送,4xx 障害(C),5xx 障害(S))が配置されています.

検索窓にコード番号(例:「404」)や名称(例:「Not Found」),あるいは日本語訳や説明文に含まれるキーワードを入力すると,該当するステータスコードが即座に左側のリストに絞り込まれて表示されます.タブを切り替えることで特定のクラスのみをフィルタリングすることも可能であり,未知のコードに遭遇した際のエラー早見表として素早く目的の情報に到達できます.

左側のリストから任意の項目をクリックすると,右側の詳細パネルにそのコードの定義,日本語名称,関連するRFCのセクション情報が表示されます.本ツールは学習用のAPIレスポンスカタログとして,想定されるHTTPレスポンスヘッダーやボディ(JSONやHTML)の例示も確認できる仕組みとなっています.

ここで提供される情報は,あくまで代表的な23種類のコードに限定された抜粋です.すべてのステータスコードを網羅しているわけではないため,IANA(Internet Assigned Numbers Authority)が管理する公式な登録一覧を完全に代替するものではありません.

しかし,日常的な開発業務において頻出するステータスコードの意味を素早く確認し,コード選択の妥当性を判断する用途においては十分なパフォーマンスを発揮します.

第3章

リダイレクトの挙動とキャッシュの可能性

三百番台のステータスコードは,主にリソースの移動や状態の変化に伴うクライアントへの追加アクションを指示します.本ツールでは,「301 Moved Permanently」「302 Found」「304 Not Modified」の三つを代表例として収録しています.

「301 Moved Permanently」は,要求されたリソースが恒久的に新しいURLへ移動したことを示します.多くの場合,サーバーはLocationヘッダーに新しい転送先を含めて応答します.ブラウザなどのクライアントは,この転送先をキャッシュし,次回以降は古いURLへのアクセスを自動的に新しいURLへ向けることが一般的です.

一方「302 Found」は一時的な移動を示しますが,キャッシュ可否をコードだけで決めることはできません.301と302の実際のキャッシュ動作は,Cache-ControlやExpires等の明示的な指示,ヒューリスティックな扱い,クライアント実装や設定に依存します.

「304 Not Modified」は,条件付きリクエスト(If-None-MatchやIf-Modified-Sinceを用いた要求)に対して,リソースが更新されていないことを伝えるコードです.このレスポンスには通常ボディが含まれず,クライアントは自身が保持しているローカルのキャッシュデータを再利用します.

これにより,不要なデータ転送を省き,ネットワーク帯域の節約と表示の高速化を実現できます.三百番台の詳細解説を確認する際は,こうしたヘッダーや設定値との相互作用も考慮する必要があります.

第4章

クライアントエラーの特定と対処方針

四百番台のステータスコードは,クライアントが送信したリクエストに何らかの不備があり,サーバーが処理を拒否したことを示します.フロントエンド開発やAPIクライアントの実装において,これらのコードを受け取った原因を適切に調査し,修正することは極めて重要です.

「400 Bad Request」は,不正なJSONフォーマットやパラメータの欠落など,リクエストの構文エラーを広く指すコードです.「401 Unauthorized」は認証の欠如や失敗を示し,対象リソースへのアクセスには有効なトークンなどが必要です.対照的に「403 Forbidden」は,認証自体は成功している(あるいは不要である)ものの,対象リソースに対する閲覧・操作権限がないことを意味します.

ただし,403の原因は権限不足だけでなく,WAF(Web Application Firewall)による遮断やIPアドレス制限など,インフラ層の設定に起因する場合もあります.原因を一つに断定せず,システムの構成全体を確認することが解決への近道となります.

Web上で最も認知度の高い「404 Not Found」は,要求されたリソースが存在しないことを示しますが,セキュリティ上の理由から403の代わりに返却されるケースも存在します.また,「429 Too Many Requests」はレートリミット(APIの呼び出し回数制限)の超過を表します.

429を受信した際,サーバーによっては再試行までの猶予秒数を示すRetry-Afterヘッダーが付与されることがあります.しかし,これも常に付与される保証はなく,APIの仕様書や実際のレスポンスヘッダーをツールで確認しながら,適切なバックオフ(待機)処理を実装する必要があります.

第5章

サーバーエラーの調査とネットワークの切り分け

五百番台のステータスコードは,サーバー側で予期せぬ例外が発生した,あるいは過負荷などにより正常に処理を完了できなかった状態を示します.クライアント側のリクエスト自体は正しい場合が多いため,エラー早見表を用いてインフラやバックエンドアプリケーションのどの層に問題が起きているかを切り分ける調査が求められます.

「500 Internal Server Error」は,プログラムのバグ,データベース接続の失敗,設定ファイルの記述ミスなど,サーバー内部で発生したあらゆる障害を包括的に示す汎用的なコードです.原因を特定するためには,サーバー側のアプリケーションログやエラー監視ツールを確認する必要があります.

一方,ロードバランサーやリバースプロキシ(Nginxなど),APIゲートウェイを経由するシステムアーキテクチャでは,「502 Bad Gateway」や「504 Gateway Timeout」が頻出します.502は,プロキシサーバーが背後のアプリケーションサーバー(上流サーバー)から無効なレスポンスを受け取ったことを意味します.

これは上流サーバーのプロセスダウンやネットワーク切断が疑われます.504は,上流サーバーからの応答が設定された制限時間内に得られなかったことを示し,データベースのロックや重い処理によるタイムアウトが主な原因です.

「503 Service Unavailable」は,サーバーが一時的な過負荷状態にあるか,メンテナンス中であることを示します.この状態は一時的であることが多く,429と同様にRetry-Afterヘッダーが付与される可能性がありますが,必ず再試行が可能であると断定できるわけではありません.システムの負荷状況や運用ポリシーに応じて,適切な対処方針を検討する必要があります.

第6章

学習用レスポンス例示と公式仕様の確認

本ツールでは,各ステータスコードを選択した際,画面右側の詳細解説パネルに「APIレスポンスのモック例」としてHTTPレスポンスヘッダーとボディのサンプルを表示します.これらは,特定のコードが実際の通信においてどのような形式で返却されるかをイメージするための学習用データとして提供されています.

例えば,200番台の成功時にはJSON形式のデータが返却される例,400番台のエラー時にはエラー内容を説明するメッセージが格納される例,500番台のインフラエラー時にはHTMLのエラーページが返却される例などを確認できます.詳細パネルのコピー操作はクリップボードAPIの成功を待機し,失敗時にはエラーが明示されます.

またステータスコードの選択や検索キーワード,分類タブを変更すると前回のコピー状態表示は失効してリセットされ,本文が存在しないステータス例では本文コピーボタン自体が表示されません.これらの表示例は,ローカルでのテスト用モックサーバーの設定やAPI仕様策定の参考資料として活用できます.

ただし,ここで表示される内容はあくまで一例に過ぎません.実際のWebアプリケーションやAPIサーバーが返すヘッダーの組み合わせ,エラーレスポンスのJSON構造,キャッシュ制御のディレクティブは,利用しているフレームワークやサーバーの個別設定によって千差万別です.本ツールの例示をそのまま実稼働環境の仕様として断定・流用することは避け,必ず開発対象のシステムの実際の挙動を確認してください.

さらに,本ツールは代表的な23コードを抜粋したエラー早見表であり,HTTPプロトコルで定義されているすべてのステータスコードを網羅しているわけではありません.未収録のコードに遭遇した場合や,各コードの厳密な定義,RFCでの記述を深く理解したい場合は,IANA(Internet Assigned Numbers Authority)が公開している公式のHTTP Status Code Registryを参照し,標準仕様に基づいた一次情報にアクセスすることを推奨します.

よくある質問(FAQ)

A.
いいえ.代表的な23コードの抜粋です.未収録コードと最新の登録状況はIANA HTTP Status Code Registryで確認してください.
A.
一律には決まりません.Cache-Control等の応答ヘッダー,HTTPキャッシュ仕様,クライアント実装が挙動に影響します.
A.
例では付けていますが,実際の応答で常に付くとは限りません.API仕様と受信したヘッダーを確認してください.
A.
構造を理解するための例であり,特定APIの契約ではありません.対象の仕様書,実応答,セキュリティ要件に合わせてください.