すべてのHTTPステータスコードの完全なリファレンス（説明と例付き）。
61件中61件を表示
4件のステータスコード
サーバーがリクエストヘッダーを受信し、クライアントはリクエストボディの送信を続行すべきです。これは、完全なペイロードを送信する前にサーバーがリクエストを受け入れるかどうかをクライアントが確認できるようにすることで、大容量アップロードを最適化するために使用されます。
一般的なユースケース: クライアントが大容量のリクエストボディをアップロードする前にExpect: 100-continueヘッダーを送信する際に使用され、サーバーが帯域幅を無駄にすることなく早期にリクエストを拒否できるようにします。
クライアントがUpgradeヘッダーで要求したとおり、サーバーが別のプロトコルに切り替えています。サーバーは同意し、このレスポンス後は新しいプロトコルで通信します。
一般的なユースケース: HTTP接続をWebSocket接続にアップグレードする際に最もよく見られます。クライアントがUpgrade: websocketヘッダーを送信し、サーバーが101で応答して切り替えを確認します。
サーバーはリクエストを受信して処理していますが、まだレスポンスは利用できません。これにより、サーバーが長時間の処理を行っている間にクライアントがタイムアウトすることを防ぎます。
一般的なユースケース: 完了までに時間がかかる可能性のあるWebDAV操作で使用されます。サーバーが接続を切断しておらず、まだリクエストの処理中であることをクライアントに通知します。
サーバーが最終的なレスポンスの前に予備的なレスポンスヘッダーを送信します。これにより、サーバーがまだ完全なレスポンスを準備している間に、クライアントがリソースのプリロードを開始できます。
一般的なユースケース: Linkヘッダーを早期に送信して、最終的なHTMLレスポンスが到着する前にブラウザがCSS、JavaScript、またはフォントをプリロードできるようにし、ページの読み込みパフォーマンスを向上させるために使用されます。
10件のステータスコード
リクエストは成功しました。成功の意味はHTTPメソッドによって異なります：GETは要求されたリソースを返し、POSTはアクションの結果を返します。
一般的なユースケース: ほとんどのAPI呼び出しの標準的な成功レスポンス。GETリクエストがデータを返す場合、PUTリクエストがリソースを更新する場合、または操作がレスポンスボディ付きで正常に完了する場合に使用されます。
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 42,
"name": "Jane Doe",
"email": "jane@example.com",
"created_at": "2025-08-15T10:30:00Z"
}リクエストが満たされ、新しいリソースが作成されました。レスポンスには通常、新しく作成されたリソースを指すLocationヘッダーが含まれます。
一般的なユースケース: 新しいリソースを作成する成功したPOSTリクエストの後に返されます。例えば、新しいユーザーアカウントの作成、ブログ記事の追加、またはファイルのアップロードなどです。
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"name": "Jane Doe",
"email": "jane@example.com"
}HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42
{
"id": 42,
"name": "Jane Doe",
"email": "jane@example.com",
"created_at": "2025-08-15T10:30:00Z"
}リクエストは処理のために受理されましたが、処理はまだ完了していません。リクエストは最終的に実行される場合もされない場合もあり、実際の処理時に拒否される可能性があります。
一般的なユースケース: サーバーがタスクを後で処理するためにキューに入れる非同期操作に使用されます。例えば、メールの送信、レポートの生成、またはバッチジョブのトリガーなどです。
リクエストは成功しましたが、ヘッダーで返されたメタデータはオリジンサーバーからではなく、ローカルまたはサードパーティのコピーから取得されたものである可能性があります。含まれるペイロードは、オリジンサーバーの200レスポンスの修正版です。
一般的なユースケース: 実際にはほとんど使用されません。変換プロキシがオリジンサーバーのレスポンスヘッダーを変更した場合に発生することがあり、メタデータが元のものと一致しない可能性があることを示します。
サーバーはリクエストを正常に処理しましたが、レスポンスのペイロードボディに送信する追加コンテンツはありません。レスポンスには更新されたヘッダーが含まれる場合があります。
一般的なユースケース: 成功したDELETEリクエストの後、またはレスポンスボディが不要なPUT/PATCH更新の後に返されます。確認応答だけで十分なファイアアンドフォーゲット操作にも使用されます。
DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 204 No Contentサーバーはリクエストを処理し、リクエストの送信を引き起こしたドキュメントビューをユーザーエージェントにリセットするよう要求しています。レスポンスボディは含まれません。
一般的なユースケース: リクエストを送信したフォームまたはUIをリセットするようクライアントに通知するために使用されます。例えば、フォームの送信が成功した後、サーバーがブラウザにフォームフィールドをクリアするよう指示できます。
クライアントが送信したRangeヘッダーにより、サーバーはリソースの一部のみを配信しています。これはレジューム可能なダウンロードやメディアストリーミングに使用されます。
一般的なユースケース: クライアントが大きなファイルの特定のバイト範囲を要求する際に使用され、レジューム可能なダウンロード、動画シーク、並列チャンクダウンロードなどの機能を可能にします。
複数のステータスコードが適切である状況で、複数のリソースに関する情報を伝えるWebDAVレスポンス。レスポンスボディは、各サブリクエストの個別のステータスコードを含むXMLドキュメントです。
一般的なユースケース: 各サブ操作が異なる結果を持つ可能性のあるWebDAVバッチ操作で使用されます。例えば、複数のファイルをコピーする際に、一部は成功し一部は失敗する場合です。
DAV: propstatレスポンス要素内で、同じコレクションへの複数のバインディングの内部メンバーを繰り返し列挙することを避けるために使用されます。
一般的なユースケース: バインディングによりコレクション内の複数の場所に表示される同じリソースを複数回リストすることを避けるために使用されるWebDAVステータスです。
サーバーはリソースに対するGETリクエストを処理し、レスポンスは現在のインスタンスに適用された1つ以上のインスタンス操作の結果の表現です。
一般的なユースケース: デルタエンコーディングと共に使用され、リソースの現在のバージョンと以前にキャッシュされたバージョンの間の変更（デルタ）のみを送信し、帯域幅の使用量を削減します。
7件のステータスコード
ターゲットリソースには複数の表現があり、ユーザーまたはユーザーエージェントは優先するものを選択できます。サーバーは利用可能な表現のリストを含めることができます。
一般的なユースケース: 実際にはほとんど使用されません。リソースが複数の形式（例：JSON、XML、HTML）で利用可能で、サーバーがクライアントに明示的に選択させたい場合に使用される可能性があります。
ターゲットリソースに新しい永続的なURIが割り当てられ、このリソースへの将来の参照はすべて返されたLocation URIを使用すべきです。検索エンジンはインデックスを更新します。
一般的なユースケース: ページまたはAPIエンドポイントが新しいURLに恒久的に移動した場合に使用されます。ウェブサイトの再構築、ドメイン名の変更、または古いURLパターンの廃止時のSEOに不可欠です。
GET /old-page HTTP/1.1
Host: www.example.comHTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html
<html><body>This page has moved to <a href="https://www.example.com/new-page">/new-page</a>.</body></html>ターゲットリソースは一時的に別のURIの下に存在しています。リダイレクトが変更される可能性があるため、クライアントは将来のリクエストに元のURIを引き続き使用すべきです。
一般的なユースケース: ログインページへのリダイレクト、メンテナンスページへのユーザー誘導、または異なるページバージョンのA/Bテストなど、一時的なリダイレクトに使用されます。
GET /dashboard HTTP/1.1
Host: www.example.comHTTP/1.1 302 Found
Location: https://www.example.com/login?redirect=/dashboardサーバーは、通常POST操作の後に、GETリクエストを使用してユーザーエージェントを別のリソースにリダイレクトしています。これにより、クライアントがフォームデータを再送信しないことが保証されます。
一般的なユースケース: POSTフォーム送信後に確認ページにリダイレクトするために使用されます（Post/Redirect/Getパターン）。ユーザーがページを更新した際のフォームの重複送信を防ぎます。
リクエストヘッダーのIf-Modified-SinceまたはIf-None-Matchで指定されたバージョン以降、リソースは変更されていません。サーバーはリソースボディを再送信する必要はありません。
一般的なユースケース: クライアントが条件付きリクエストを行い、リソースが変更されていない場合に返され、クライアントがキャッシュされたコピーを使用できるようにします。これにより帯域幅が節約され、読み込み時間が改善されます。
GET /api/users/42 HTTP/1.1
Host: api.example.com
If-None-Match: "etag-abc123"HTTP/1.1 304 Not Modified
ETag: "etag-abc123"
Cache-Control: max-age=3600ターゲットリソースは一時的に別のURIの下に存在しており、ユーザーエージェントはリダイレクトに従う際にリクエストメソッドを変更してはなりません。302とは異なり、メソッドとボディは同じままであることが保証されます。
一般的なユースケース: HTTPメソッドを厳密に保持する一時的なリダイレクトが必要な場合に使用されます。例えば、POSTリクエストをGETに変更せずに別のエンドポイントにリダイレクトする場合です。
ターゲットリソースに新しい永続的なURIが割り当てられました。301と同様ですが、リダイレクトに従う際にリクエストメソッドとボディを変更してはなりません。
一般的なユースケース: HTTPメソッドを保持する必要がある恒久的なリダイレクトに使用されます。例えば、クライアントが引き続きPOSTリクエストを送信することを保証しながら、POSTエンドポイントを恒久的にリダイレクトする場合です。
29件のステータスコード
不正なリクエスト構文、無効なリクエストフレーミング、または欺瞞的なリクエストルーティングなど、クライアントエラーと見なされるものにより、サーバーはリクエストを処理できないか、処理しません。
一般的なユースケース: リクエストボディが不正なJSON、必須フィールドの欠落、クエリパラメータの無効、またはリクエストが期待される形式に準拠していない場合に返されます。
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"name": "",
"email": "not-an-email"
}HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "validation_error",
"message": "Request validation failed",
"details": [
{ "field": "name", "message": "Name is required" },
{ "field": "email", "message": "Must be a valid email address" }
]
}ターゲットリソースに対する有効な認証資格情報がないため、リクエストは適用されていません。レスポンスには、適用可能な認証スキームを示すWWW-Authenticateヘッダーが含まれている必要があります。
一般的なユースケース: リクエストに認証資格情報がない場合、または提供されたトークン/資格情報が期限切れまたは無効な場合に返されます。クライアントは再試行する前に認証を行う必要があります。
GET /api/users/me HTTP/1.1
Host: api.example.comHTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer
{
"error": "unauthorized",
"message": "Authentication required. Please provide a valid Bearer token."
}将来の使用のために予約されています。元々はデジタル決済スキーム向けに意図されていましたが、このステータスコードは広く標準化されていませんが、支払いが必要であることを示すためにAPIで使用されることがあります。
一般的なユースケース: 公式には予約されていますが、一部のAPIでは有料機能やサブスクリプションが必要であること、またはユーザーが無料枠の使用制限を超えたことを示すために使用されます。
サーバーはリクエストを理解しましたが、承認を拒否します。401とは異なり、認証を行っても解決しません。クライアントにはリソースに対する必要な権限がありません。
一般的なユースケース: ユーザーが認証されているが必要な権限を持っていない場合に返されます。例えば、一般ユーザーが管理者専用エンドポイントにアクセスしようとした場合や、他のユーザーが所有するリソースにアクセスした場合です。
DELETE /api/users/99 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 403 Forbidden
Content-Type: application/json
{
"error": "forbidden",
"message": "You do not have permission to delete this user. Admin role required."
}オリジンサーバーはターゲットリソースの現在の表現を見つけられなかったか、その存在を開示する意思がありません。これは一時的または永続的である可能性があります。
一般的なユースケース: 最もよく遭遇するエラーです。要求されたリソースが存在しない場合に返されます。例えば、データベースに存在しないIDでユーザーを要求した場合や、一致するルートがないURLにアクセスした場合です。
GET /api/users/99999 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 404 Not Found
Content-Type: application/json
{
"error": "not_found",
"message": "User with ID 99999 was not found"
}リクエスト行で受信されたメソッドはオリジンサーバーに認識されていますが、ターゲットリソースではサポートされていません。レスポンスには有効なメソッドをリストするAllowヘッダーが含まれている必要があります。
一般的なユースケース: HTTPメソッドがエンドポイントでサポートされていない場合に返されます。例えば、読み取り専用リソースにDELETEリクエストを送信した場合や、GETのみをサポートするエンドポイントにPOSTを送信した場合です。
DELETE /api/reports/monthly HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Allow: GET, HEAD
{
"error": "method_not_allowed",
"message": "DELETE is not allowed on this resource. Allowed methods: GET, HEAD"
}リクエストで受信されたプロアクティブなコンテンツネゴシエーションヘッダーに基づいて、ターゲットリソースにはユーザーエージェントに受け入れ可能な表現がありません。
一般的なユースケース: サーバーがクライアントから送信されたAcceptヘッダーに一致するレスポンスを生成できない場合に返されます。例えば、クライアントがXMLを要求しているがAPIがJSONのみをサポートしている場合です。
401と似ていますが、クライアントはプロキシで認証を行う必要があります。プロキシは適用可能なチャレンジを含むProxy-Authenticateヘッダーを返す必要があります。
一般的なユースケース: クライアントがプロキシ自体に対する有効な資格情報を提供していない場合にプロキシサーバーによって返されます。送信トラフィックが認証済みプロキシを経由する企業ネットワーク環境で一般的です。
サーバーは待機する準備ができていた時間内に完全なリクエストメッセージを受信しませんでした。クライアントは後で変更なしにリクエストを繰り返すことができます。
一般的なユースケース: クライアントが完全なリクエストを送信するのに時間がかかりすぎる場合に返されます。遅い接続、信頼性の低いネットワーク上の大容量アップロード、またはクライアントが接続を開いたがデータを送信しない場合に発生する可能性があります。
ターゲットリソースの現在の状態との競合のため、リクエストを完了できませんでした。クライアントは競合を解決してリクエストを再送信できるはずです。
一般的なユースケース: リクエストが既存のデータと競合する場合に使用されます。例えば、既に存在するメールアドレスでユーザーを作成しようとした場合や、最後の取得以降に別のリクエストによって変更されたリソースを更新しようとした場合です。
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"name": "Jane Doe",
"email": "jane@example.com"
}HTTP/1.1 409 Conflict
Content-Type: application/json
{
"error": "conflict",
"message": "A user with email jane@example.com already exists",
"existing_id": 42
}ターゲットリソースはオリジンサーバーで利用できなくなり、この状態は永続的である可能性が高いです。404とは異なり、リソースがかつて存在していたが意図的に削除されたことを明示的に示します。
一般的なユースケース: リソースが意図的かつ永続的に削除された場合に使用されます。一時的な可能性がある404とは異なり、検索エンジンにURLをインデックスから削除すべきであることを通知します。
サーバーは定義されたContent-Lengthヘッダーなしのリクエストを拒否します。有効なContent-Lengthヘッダーが追加されれば、クライアントはリクエストを繰り返すことができます。
一般的なユースケース: サーバーがリクエストにContent-Lengthヘッダーの存在を要求する場合に返されます。通常、サーバーがペイロードサイズを事前に知る必要があるアップロードやPOSTリクエストで発生します。
リクエストヘッダーフィールドで指定された1つ以上の条件がサーバーでのテスト時にfalseと評価されました。If-MatchやIf-Unmodified-Sinceなどの条件付きリクエストで使用されます。
一般的なユースケース: クライアントの最後の取得以降にリソースが変更されたため、条件付き更新が失敗した場合に返されます。APIにおける楽観的同時実行制御の実装に使用されます。
リクエストペイロードがサーバーが処理可能または処理を望む量を超えているため、サーバーはリクエストの処理を拒否しています。サーバーは接続を閉じるかRetry-Afterヘッダーを返す場合があります。
一般的なユースケース: ファイルアップロードまたはリクエストボディがサーバーの設定された最大サイズ制限を超えた場合に返されます。例えば、10MB制限のエンドポイントに100MBのファイルをアップロードする場合です。
リクエストターゲットがサーバーが解釈する意思のある長さを超えているため、サーバーはリクエストの処理を拒否しています。GETリクエストのクエリパラメータが過度に長い場合に発生する可能性があります。
一般的なユースケース: URLがサーバーの最大長を超えた場合に返されます。データをPOSTリクエストボディで送信する代わりにクエリパラメータにエンコードしすぎた場合によく発生します。
ペイロードがターゲットリソースのこのメソッドでサポートされていない形式であるため、オリジンサーバーはリクエストの処理を拒否しています。Content-TypeまたはContent-Encodingが受け入れられません。
一般的なユースケース: サーバーがリクエストで送信されたContent-Typeをサポートしていない場合に返されます。例えば、application/jsonのみを受け付けるエンドポイントにform-urlencodedデータを送信した場合です。
リクエストのRangeヘッダーフィールドの範囲セットが拒否されました。要求された範囲のいずれも選択された表現に対して満たすことができないためです。
一般的なユースケース: クライアントがリソースのサイズを超えるバイト範囲を要求した場合に返されます。例えば、500バイトのファイルのバイト1000-2000を要求した場合です。
リクエストのExpectヘッダーフィールドで指定された期待を、少なくとも1つの受信サーバーが満たすことができませんでした。
一般的なユースケース: サーバーがExpectヘッダーで指定された要件を満たせない場合に返されます。最も一般的にはExpect: 100-continueメカニズムに関連し、サーバーがボディ送信前にリクエストを拒否する場合です。
ティーポットでコーヒーを淹れようとする試みは、このエラーコードになるべきです。これはHyper Text Coffee Pot Control Protocolでエイプリルフールのジョークとして定義されましたが、文化的な名所として保存されています。
一般的なユースケース: エイプリルフールのRFCからのイースターエッグステータスコードです。APIでユーモラスな応答として使用されたり、サーバーが不合理と見なすリクエストを意図的に拒否するために使用されることがあります。
リクエストがレスポンスを生成できないサーバーに向けられました。これは、サーバーがリクエストURIのスキームと権限の組み合わせに対するレスポンスを生成するように構成されていない場合に発生する可能性があります。
一般的なユースケース: HTTP/2で、サーバーが処理できない別のホスト名に対して接続が再利用された場合に発生する可能性があります。クライアントは別の接続でリクエストを再試行すべきです。
サーバーはコンテンツタイプを理解し、リクエストの構文は正しいですが、含まれている指示を処理できませんでした。リクエストは整形式ですが意味的に無効です。
一般的なユースケース: リクエストボディが構文的に有効なJSONであるがビジネスロジックの検証に失敗する場合に使用されます。例えば、負の価格の設定、過去の会議のスケジュール、または開始日より前の終了日の指定などです。
POST /api/events HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"title": "Team Meeting",
"start_date": "2025-12-01",
"end_date": "2025-11-01"
}HTTP/1.1 422 Unprocessable Content
Content-Type: application/json
{
"error": "unprocessable_entity",
"message": "Semantic validation failed",
"details": [
{ "field": "end_date", "message": "End date must be after start date" }
]
}メソッドのソースまたは宛先リソースがロックされています。クライアントは後で再試行するか、ロック解除を要求すべきです。
一般的なユースケース: WebDAVでリソースが別のユーザーまたはプロセスによってロックされている場合に使用されます。APIでもリソースが別のユーザーによる編集のために一時的にロックされていることを示すために使用できます。
要求されたアクションが失敗した別のアクションに依存していたため、リソースに対してメソッドを実行できませんでした。
一般的なユースケース: WebDAVで、依存する前提操作も失敗したために操作が失敗する場合に使用されます。例えば、子ファイルの1つのコピーが失敗したためにディレクトリのコピーが失敗する場合です。
TLS 1.3アーリーデータ（0-RTT）使用時の潜在的なリプレイ攻撃を避けるため、サーバーはリプレイされる可能性のあるリクエストを処理するリスクを負いたくありません。
一般的なユースケース: リクエストがTLS 1.3アーリーデータ（0-RTT）で到着し、サーバーがそれがまだ処理されていないことを保証できない場合に使用されます。非冪等リクエストに対するリプレイ攻撃を防ぎます。
サーバーは現在のプロトコルを使用してリクエストを実行することを拒否しますが、クライアントが別のプロトコルにアップグレードした後なら実行する可能性があります。サーバーは必要なプロトコルを示すUpgradeヘッダーを含める必要があります。
一般的なユースケース: サーバーがクライアントに新しいプロトコルバージョンへの切り替えを要求する場合に使用されます。例えば、HTTP/1.1からHTTP/2へのアップグレード、または暗号化されていない接続からTLSへの切り替えなどです。
オリジンサーバーはリクエストが条件付きであることを要求しています。これは、クライアントがGETでリソースを取得し、変更し、PUTで返す間に別のクライアントも変更している「更新の喪失」問題を防ぐことを目的としています。
一般的なユースケース: サーバーが同時変更の問題を防ぐためにIf-MatchやIf-Unmodified-Sinceなどの条件付きヘッダーを要求する場合に返されます。クライアントに楽観的ロックの実装を強制します。
ユーザーが指定された時間内にあまりにも多くのリクエストを送信しました（レート制限）。レスポンスには新しいリクエストを行うまでの待ち時間を示すRetry-Afterヘッダーが含まれるべきです。
一般的なユースケース: クライアントがAPIレート制限を超えた場合に返されます。ほとんどのAPIが不正利用からの保護と公正な使用の確保のためにこれを使用します。クライアントはRetry-Afterヘッダーで指定された時間の後にバックオフして再試行すべきです。
GET /api/search?q=test HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600
{
"error": "rate_limit_exceeded",
"message": "Rate limit exceeded. Maximum 100 requests per minute.",
"retry_after": 60
}リクエストのヘッダーフィールドが大きすぎるため、サーバーはリクエストの処理を行いません。リクエストヘッダーフィールドのサイズを縮小した後、リクエストを再送信できます。
一般的なユースケース: リクエストヘッダーがサーバーのサイズ制限を超えた場合に返されます。Cookieが大きくなりすぎた場合や、カスタムヘッダーや過大なAuthorizationトークンに多くのデータが渡された場合によく発生します。
法的要求の結果として、サーバーはリソースへのアクセスを拒否しています。レスポンスにはボディに法的制限の説明と、法的権限を識別するLinkヘッダーが含まれるべきです。
一般的なユースケース: 政府の検閲命令、DMCA削除通知、裁判所命令、または制裁遵守などの法的要件によりリソースがブロックされている場合に使用されます。コード番号はFahrenheit 451を参照しています。
11件のステータスコード
サーバーがリクエストの処理を妨げる予期しない状況に遭遇しました。より具体的な5xxステータスコードが適切でない場合の汎用的なキャッチオールエラーです。
一般的なユースケース: 最も一般的なサーバーエラーです。サーバーが未処理の例外、バグ、データベース接続の失敗、またはリクエスト処理中のその他の予期しない問題に遭遇した場合に返されます。
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{
"error": "internal_server_error",
"message": "An unexpected error occurred. Please try again later.",
"request_id": "req_abc123xyz"
}サーバーはリクエストを処理するために必要な機能をサポートしていません。サーバーがリクエストメソッドを認識せず、サポートできない場合の適切なレスポンスです。
一般的なユースケース: サーバーが要求されたHTTPメソッドを認識しないか、まだ実装していない場合に返されます。計画されているがまだ構築されていないAPIエンドポイントのプレースホルダーとして使用できます。
サーバーがゲートウェイまたはプロキシとして動作中に、リクエストの処理のためにアクセスした上流サーバーから無効なレスポンスを受信しました。
一般的なユースケース: リバースプロキシ、ロードバランサー、またはAPIゲートウェイによって返され、上流のアプリケーションサーバーが不正なレスポンスを送信したり、クラッシュしたり、到達不能な場合に発生します。デプロイ中によく見られます。
HTTP/1.1 502 Bad Gateway
Content-Type: application/json
{
"error": "bad_gateway",
"message": "The upstream server returned an invalid response. Please try again shortly."
}一時的な過負荷またはスケジュールされたメンテナンスにより、サーバーは現在リクエストを処理できません。これは一時的な状態であり、サーバーはまもなく再び利用可能になることを意味します。
一般的なユースケース: 計画されたメンテナンスウィンドウ中、サーバーが過負荷の場合、または重要な依存関係がダウンしている場合に返されます。Retry-Afterヘッダーでクライアントがいつ再試行すべきかを示すことができます。
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300
{
"error": "service_unavailable",
"message": "Service is temporarily unavailable for scheduled maintenance. Expected back at 2025-12-01T03:00:00Z.",
"retry_after": 300
}サーバーがゲートウェイまたはプロキシとして動作中に、リクエストの完了に必要な上流サーバーから適時にレスポンスを受信できませんでした。
一般的なユースケース: リバースプロキシまたはロードバランサーによって返され、上流のアプリケーションサーバーのレスポンスに時間がかかりすぎる場合に発生します。遅いデータベースクエリ、外部APIのタイムアウト、または過負荷のバックエンドを示すことが多いです。
サーバーはリクエストメッセージで使用されたHTTPのメジャーバージョンをサポートしていないか、サポートを拒否しています。
一般的なユースケース: サーバーがリクエストで使用されたHTTPプロトコルバージョンをサポートしていない場合に返されます。例えば、HTTP/1.1のみをサポートするサーバーが処理できないHTTP/2リクエストを受信した場合です。
サーバーに内部設定エラーがあります：選択されたバリアントリソース自体が透過的コンテンツネゴシエーションに参加するように構成されており、循環参照が発生しています。
一般的なユースケース: サーバー側のコンテンツネゴシエーションの設定ミスを示す稀なエラーで、ネゴシエートされたリソース自体がネゴシエートしようとし、無限ループを引き起こします。
サーバーがリクエストを正常に完了するために必要な表現を保存できないため、リソースに対してメソッドを実行できませんでした。
一般的なユースケース: サーバーがデータの書き込み中にディスク容量またはストレージクォータが不足した場合に返されるWebDAVステータスです。ストレージ制限に達したAPIにも適用できます。
Depth: infinityのリクエストを処理中に無限ループを検出したため、サーバーが操作を終了しました。これは500のより具体的なバージョンです。
一般的なユースケース: サーバーがリソースバインディングにおける循環依存または無限ループを検出した場合に返されるWebDAVステータスです。例えば、自身を参照するディレクトリ構造などです。
リソースへのアクセスポリシーがリクエストで満たされていません。サーバーはクライアントが拡張リクエストを発行するために必要なすべての情報を返すべきです。
一般的なユースケース: サーバーがリクエストを処理するためにリクエストへの追加の拡張が必要であることを示す、めったに使用されないステータスコードです。HTTP Extension Framework仕様で定義されています。
クライアントはネットワークアクセスを得るために認証を行う必要があります。これはHTTPレベルの認証ではなく、キャプティブポータルへのログインなどのネットワークレベルのアクセスに関するものです。
一般的なユースケース: ユーザーがまだネットワークでの認証を行っていない場合に、キャプティブポータル（例：ホテルや空港のWi-Fiログインページ）によって返されます。レスポンスボディには通常ログインページが含まれます。