前回は、Webの成功理由とも言われる8つしかないHTTPメソッドについてまとめた。ここでは、レスポンスメッセージの意味を伝える数字であるステータスコードについて説明する。
１ ステータスコードの重要性
ステータスコードは、クライアントの挙動を左右する重要な役割を担っている。クライアントを混乱させないためにも、仕様で定められたステータスコードの意味を正しく理解する必要がある。
２ ステータスラインの復習
ステータスラインとは、レスポンスメッセージの1行目にあるもので、プロトコルバージョン、ステータスコード、テキストフレーズからなる。このうち最も重要なのが、ステータスコードである。
３ ステータスコードの分類と意味
HTTP 1.1ではのステータスコードはRFC2616の6.1.1節で定義されている。ステータスコードは3桁の数字であり、先頭の数字によって以下の5つに分類される。
- 1xx：処理中。処理が継続していることを示す。クライアントはそのままリクエストを継続するか、サーバの指示に従ってプロトコルをアップデートして再送信する
- 2xx：成功。リクエストが成功したことを示す
- 3xx：リダイレクト。他のリソースへのリダイレクトを示す。クライアントはレスポンスメッセージのLocationヘッダを見て新しいリソースへ接続する
- 4xx：クライアントエラー。原因はクライアントのリクエストにある。エラーを解消しない限り正常な結果が得られないので、同じリクエストをそのまま再送信することはできない
- 5xx：サーバエラー。サーバエラー。原因はサーバ側にある
ステータスコードを先頭の数字で分類するのは、クライアントとサーバの約束事を最小限に抑えて、クライアントとサーバの結びつきをなるべく緩やかにする（疎結合にする）ための工夫である。この工夫によって、サーバのバージョンアップやクライアントの置き換えが行いやすくなる。また、未知のステータスコードが来ても、先頭数字の約束が守られていればクライアントは最低限の処理ができる。
４ よく使われるステータスコード
ここでは最も使われているステータスコードを9つ解説する。ステータスコードの一覧はIANAが管理している。定義済みのすべてのステータスコードは、最後に付録としてまとめる。
200 OK—リクエスト成功
200 OKはリクエストが成功したことを示す。GETの場合はボディにリソースの表現が入り、PUTやPOSTの場合は処理結果が入る。
201 Created—リソースの作成成功
201 Createdはリソースを新たに作成したことを示す。POSTとPUTのレスポンスとして返る。POSTの場合、新しく作成したリソースURIはレスポンスのLocationヘッダに絶対URIとして入る。PUTの場合、クライアントが新しいリソースのURIを知っているためLocationヘッダは入らない。
301—Moved Permanently—リソースの恒久的な移動
301 Moved Permanentlyは、リクエストで指定したリソースが新しいURIに移動したことを示す。古いURIを保ちつつ、新しいURIに移行する際にこのステータスコードを用いる。新しいURIはレスポンスのLocationヘッダに絶対URIとして入る。
303 See Other—別URIの参照
303 See Otherは、リクエストに対する処理結果が別のURIで取得できることを示す。例えば、ブラウザからPOSTでリソースを操作した結果をGETで取得するときに使う。
400 Bad Request—リクエストの間違い
400 Bad Requestは、リクエストの構文やパラメータが間違っていたことを示す。
401 Unauthorized—アクセス権不正
401 Unauthorizedは、適切な認証情報を与えずにリクエストを行ったことを示す。レスポンスのWWW-Authenticateヘッダで、クライアントに対して認証方式を伝える。
404 Not Found—リソースの不在
404 Not Foundは、指定したリソースが見つからないことを示す。レスポンスボディにはその理由が入る。
500 Internal Server Errorーサーバ内部エラー
500 Internal Server Errorは、サーバ側に何らかの異常が生じていて、正しいレスポンスが返せないことを示す。レスポンスボディには異常の理由が入る。また、他に適切なサーバエラーを示すステータスコードがない場合にも用いる。
503 Service Unavailable—サービス停止
503 Service Unavailableは、サーバがメンテナンスなどで一時的にアクセスできないことを示す。レスポンスボディにはその理由が入る。レスポンスのRetry-Afterヘッダでサービス再開時期がおよそ何秒後であるかを通知することもできる。
５ ステータスコードとエラー処理
4xx系と5xx系のステータスコードはどちらもエラーを表現する。エラーコード（ステータスコード）はHTTP仕様が規定しているが、ボディにどんなエラーメッセージを入れるかは規定していない。通常のWebサービスではエラーメッセージがHTMLで問題ないが、Web APIの場合はクライアントが解釈できる形式でエラーメッセージを返してあげると親切である。
プロトコルに従ったフォーマットでエラーを返す
例えば、AtomPubを利用したWeb APIの場合、エラーメッセージはAtomで返すのがひとつの方法である。
Acceptヘッダに応じたフォーマットでエラーを返す
クライアントがAcceptヘッダを送信している場合は、それを利用してエラー情報の表現を動的に変更できる。
６ ステータスコードの誤用
一部のWebサービスやWeb APIでは、エラーを200 OKで返すことがある。そうすると、検索エンジンのロボットが正式なリソースであると勘違いし、インデックス処理が行われてしまったり、正常結果としてボディを表示してしまう可能性がある。そのため、HTTPのステータスコードを正しく使うことは最低限のマナーである。
７ ステータスコードを意識して設計する
開発しているWebサービスやWeb APIでエラーが起きたときに、どのステータスコードを返すかは、とても重要な設計の検討事項である。ステータスコードは仕様で固定されているため、正しく使うことが求められるのである。
付録A
1xx：処理中
- 100 Continue
- 101 Switching Protocols
2xx：成功
- 200 OK
- 201 Created
- 202 Accepted
- 203 Non-Authoritative Information
- 204 No Content
- 205 Reset Content
- 206 Partial Content
- 207 Multi-Status
3xx：リダイレクト
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 305 Use Proxy
- 307 Temporary Redirected
4xx：クライアントエラー
- 400 Bad Request
- 401 Unauthorized
- 402 Payment Required
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication Required
- 408 Request Timeout
- 409 Conflict
- 410 Gone
- 411 Length Required
- 412 Precondition Failed
- 413 Request Entity Too Large
- 414 Request-URI Too Long
- 415 Unsupported Media Type
- 416 Requested Range Not Satisfiable
- 417 Expectation Failed
- 422 Unprocessable Entity
- 423 Locked
- 424 Failed Dependency
5xx：サーバエラー
- 500 Internal Server Error
- 501 Not Implemented
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
- 505 HTTP Version Not Supported
最後に
ステータスコードは大きく5種類に分類でき、それぞれに意味がある。中でも、4xx系は他と比べて多様であることから、様々な種類のクライアントエラーが存在することを意味している。ステータスコードの実装はWebサーバやフレームワークによって異なるため、設計の段階でどのようにステータスコードを返すかを考慮することが大切である。
次回は、メッセージのボディに対する付加情報の表現であるHTTPヘッダについてまとめる。
 |
