4.6. Using HTTP Status Codes (HTTP ステータスコードの使用)

4.6. Using HTTP Status Codes (HTTP ステータスコードの使用)

HTTP を使用するアプリケーションは, 登録された HTTP ステータスコードのみを使用しなければなりません (MUST)。最も具体的に適用可能なステータスコードを使用すべきです (SHOULD) が, [HTTP] で定義されたものに限定されません; "HTTP ステータスコード" レジストリに登録されている限り, 他のステータスコードを使用できます。

ステータスコードの使用方法を指定するとき, アプリケーションは特定のコンテキストでの具体的な意味ではなく, 汎用セマンティクスに焦点を当てるべきです (SHOULD)。たとえば, 次のように言うのは適切です:

リクエストが成功した場合, サーバーは 200 OK レスポンスを送信します。

しかし, 次は適切ではありません:

ユーザーが認証され, リソースへのアクセスが承認されたときに, サーバーは 200 OK レスポンスを送信します。

後者は, 成功, 認証, 承認という複数のことを混同しているため, 過度に具体的です。より適切な記述は次のようになります:

リクエストが成功した場合, サーバーは 200 OK レスポンスを送信します。認証が必要だが提供されていない場合, サーバーは 401 Unauthorized レスポンスを送信します。クライアントがリソースへのアクセスを承認されていない場合, サーバーは 403 Forbidden レスポンスを送信します。

アプリケーションは新しいステータスコードを定義すべきではありません (SHOULD NOT)。新しいステータスコードが本当に必要なまれなケースでは, [HTTP] セクション 16.2 の手順に従って登録しなければなりません (MUST)。

ステータスコードを選択するとき, 一般原則は適用される最も具体的なものを選択することです。ステータスコードはレスポンスの主な理由を伝えるべきです。

たとえば, リソースが存在しないためにリクエストが失敗した場合, 404 Not Found が適切です。クライアントがアクセスを承認されていないために失敗した場合, リソースが存在しない可能性があっても 403 Forbidden が適切です。

アプリケーションは次のステータスコードを適切に使用すべきです (SHOULD):

• 表現を含む成功したリクエストには 200 OK。

• 新しいリソースの作成につながる成功したリクエストには 201 Created。

• 処理のために受け入れられたが処理が完了していないリクエストには 202 Accepted。

• 送信する表現がない成功したリクエストには 204 No Content。

• 永続的に移動したリソースには 301 Moved Permanently または 308 Permanent Redirect。

• 一時的に移動したリソースには 302 Found または 307 Temporary Redirect。

• リソースが変更されていない条件付きリクエストには 304 Not Modified。

• 不正な形式のリクエストには 400 Bad Request。

• 認証を必要とするリクエストには 401 Unauthorized。

• クライアントが承認されていないリクエストには 403 Forbidden。

• 存在しないリソースへのリクエストには 404 Not Found。

• 不適切なメソッドを使用するリクエストには 405 Method Not Allowed。

• サーバーがクライアントが受け入れる表現を生成できない場合は 406 Not Acceptable。

• リクエストがリソースの現在の状態と競合する場合は 409 Conflict。

• 存在していたが永久に削除されたリソースには 410 Gone。

• リクエストの Content-Type がサポートされていない場合は 415 Unsupported Media Type。

• サーバー側エラーには 500 Internal Server Error。

• サーバーが要求された機能をサポートしていない場合は 501 Not Implemented。

• サーバーが一時的にリクエストを処理できない場合は 503 Service Unavailable。