Web 開発と API 設計の世界では、HTTP ステータス コードは、クライアントとサーバーの間でリクエストの結果を伝達する際に重要な役割を果たします。これらのコードは、HTTP リクエストの処理中に発生する特定の条件、成功、またはエラーを示す標準化された方法を提供します。これらのステータス コードを理解することは、デバッグ、エラー処理、およびより堅牢なアプリケーションの作成に役立つため、開発者にとって不可欠です。

1. 1xx 情報

これらのステータス コードは暫定的な応答を示します。実際にはほとんど使用されませんが、特定のシナリオでは役立つ場合があります。

• 100 Continue: サーバーはリクエスト ヘッダーを受信したため、クライアントはリクエスト本文の送信に進む必要があります。
• 101 プロトコルの切り替え: 要求者はサーバーにプロトコルを切り替えるように要求し、サーバーはそれに同意しました。

2. 2xx の成功

これらのステータス コードは、クライアントのリクエストが正常に受信され、理解され、受け入れられたことを示します。

• 200 OK: リクエストは成功し、応答にはリクエストされたデータまたは結果が含まれています。
  • 例: ユーザーのプロフィール情報を取得します。
• 201 Created: リクエストは成功し、新しいリソースが作成されました。
  • 例: 新しいユーザー アカウントの作成または新しいブログ エントリの投稿。
• 204 コンテンツがありません: サーバーはリクエストを正常に処理しましたが、コンテンツを返しません。
  • 例: 応答本文が必要ないユーザーの設定を更新します。
• 206 部分コンテンツ: クライアントによって送信された範囲ヘッダーのため、サーバーはリソースの一部のみを配信しています。
  • 例: ビデオ コンテンツのストリーミングまたは大きなファイルを分割してダウンロードする。

3. 3xx リダイレクト

これらのステータス コードは、リクエストを満たすためにユーザー エージェントがさらにアクションを実行する必要があることを示します。

• 301 Moved Permanently: 要求されたリソースは新しい URL に永久に移動されました。
• 302 が見つかりました: 要求されたリソースは一時的に別の URL に存在します。
• 304 Not Modified: リクエスト ヘッダーで指定されたバージョン以降、リソースが変更されていないことを示します。

4. 4xx クライアント エラー

これらのステータス コードは、クライアントがエラーを犯したと思われる状況を対象としています。

• 400 Bad Request: 無効な構文または不正な入力のため、サーバーはリクエストを処理できません。

  • 例: リクエスト本文で不正な形式の JSON を送信します。
  • 使用法: リクエスト自体の形式が間違っているか、無効なパラメータが含まれている場合に使用します。

• 401 Unauthorized: リクエストにはユーザー認証が必要です。

  • 例: 有効な認証情報を提供せずに、保護された API エンドポイントにアクセスしようとしています。
  • 使用法: 認証が必要であるが、提供されていない場合、または無効な場合に使用します。

• 403 禁止: サーバーはリクエストを理解しましたが、承認を拒否しました。

  • 例: ユーザーが管理者専用機能にアクセスしようとしています。
  • 使用法: ユーザーは認証されているが、要求された操作に対する権限を持っていない場合に使用します。

• 404 見つかりません: 要求されたリソースがサーバー上に見つかりませんでした。

  • 例: 削除されたユーザー プロファイルを取得しようとしています。
  • 使用法: 要求されたリソースが存在しない場合に使用します。

• 405 メソッドは許可されません: リクエストで指定されたメソッドは、リクエスト URI で識別されるリソースに対して許可されません。

  • 例: GET リクエストのみを受け入れるエンドポイントに POST リクエストを送信します。

• 409 競合: リソースの現在の状態と競合するため、リクエストを処理できませんでした。

  • 例: システムに既に存在する電子メールを使用してユーザーを作成しようとしています。
  • 使用法: 重複エントリなど、リソースの現在の状態と矛盾がある場合に使用します。

• 422 処理できないエンティティ: サーバーはリクエストのコンテンツ タイプと構文を理解していますが、含まれている命令を処理できません。

  • 例: サーバー側の検証に失敗する無効なデータを含むフォームを送信します。
  • 使用法: リクエスト構文は正しいが、データが意味的に正しくない検証エラーに使用します。

• 429 リクエストが多すぎます: ユーザーが一定時間内に送信したリクエストが多すぎます (「レート制限」)。

  • 例: 悪用を防ぐために API レート制限を実装します。

5. 5xxサーバーエラー

これらのステータス コードは、エラーが発生したか、リクエストを実行できないことをサーバーが認識している場合を示します。

• 500 内部サーバー エラー: サーバーがリクエストの実行を妨げる予期しない状況に遭遇したことを示す一般的なエラー メッセージ。

  • 例: サーバー側のコードでハンドルされない例外が発生しました。

• 501 は実装されていません: サーバーはリクエストを満たすために必要な機能をサポートしていません。

  • 例: サーバーが認識しない新しい HTTP メソッドの使用。

• 502 不正なゲートウェイ: サーバーは、ゲートウェイまたはプロキシとして動作中に、上流サーバーから無効な応答を受信しました。

  • 例: リバース プロキシ サーバーはオリジン サーバーに接続できません。

• 503 サービスを利用できません: 一時的な過負荷またはメンテナンスのため、サーバーは現在リクエストを処理できません。

  • 例: サーバーは計画メンテナンス中か、高トラフィックが発生しています。

• 504 ゲートウェイ タイムアウト: サーバーは、ゲートウェイまたはプロキシとして動作中に、上流サーバーからタイムリーな応答を受信しませんでした。

  • 例: サードパーティ API からの応答を待機中にタイムアウトが発生しました。

HTTP ステータス コードを使用するためのベスト プラクティス

1. 具体的にする: 状況に適用される最も具体的なステータス コードを使用します。これは、クライアントが何が起こったのか、どのように対応すればよいのかを正確に理解するのに役立ちます。

2. 一貫した使用法: API 全体でステータス コードの使用方法の一貫性を維持します。これにより、開発者は API を簡単に操作できるようになります。

3. 追加情報の提供: 必要に応じて、ステータス コードとともに詳細なエラー メッセージを応答本文に含めます。これはデバッグに役立ち、開発者のエクスペリエンスが向上します。

4. セキュリティに関する考慮事項: 特に 4xx および 5xx エラーの場合、エラー応答であまりにも多くの情報を明らかにしないよう注意してください。システム アーキテクチャや実装に関する機密情報の公開は避けてください。

5. ドキュメント: API がどのステータス コードをどのような状況で使用するかを明確に文書化します。これは、API コンシューマーがさまざまな応答を解釈して処理する方法を理解するのに役立ちます。

HTTP ステータス コードを理解して適切に実装することで、開発者はより堅牢で明確でユーザー フレンドリーな API や Web アプリケーションを作成できます。これらのコードは、クライアントとサーバー間の重要な通信ツールとして機能し、エラー処理を合理化し、システム全体の信頼性を向上させるのに役立ちます。