HTTPステータスコード 3xx系 redirect

HTTP REST

300 (Multiple Choices)
あまり使わない。
要求されたリソースの表現方法が複数あり，どれを返せばよいかわからないことを示す。
クライアントがAccept-*の指定をしてなかったか，存在しない表現を要求したかのどちらか。


デフォルトを決めておいて，200とともにそれを返してもよい。
だからあまり使われない。


400を返してエラー扱いにしてしまってもよいか？それは厳しすぎか？


Locationで優先度の高いURIをつけることができる。
bodyは表現のURIリスト。HTMLがいいようだ。


301 (Moved Permanently)
リソースが移動した。恒久的に。
Locationヘッダはリソースへのパスをポイントしなければならない。
bodyには，新しいURIへリンクするHTMLがつけられるが必須ではない。


302 (Found)
使わない方がいいが，
しかしクライアント開発の場合にはこのステータスは知っておかなければならない。
HTTP/1.0では，Moved TemporaryだったがHTTP/1.1で名前が変わった。


本来は，307(Temporary Redirect)と同じように処理されるべきだったのだが，
しかしそのようなクライアントは少なく，PUT,POST,DELETEのときに
303(See Other)と同じように処理するクライアントがほとんどだった。
この問題があったため，HTTP/1.1では307(Temporary Redirect)が新設されたという経緯がある。


つまりこのステータスは曖昧なもののため，新規開発で採用すべきではない。
303か307を使うべき。
もちろん303と307を理解しないHTTP/1.0クライアントとやり取りをする場合は別である。


Locationヘッダにはredirect先のURIをポイントする必要がある。
bodyには新しいURIをリンクするHTMLを付けられるが必須ではない。


303 (See Other)
処理は完了しているが，リソースを返す代わりにリソースのURIを返す。


「本当」のURIは1つしか存在しないはずで，そのエイリアスだった場合などに使う。
たとえば /hoge/fuga/current.tar.gz が /hoge/fuga/1.2.3.tar.gz のエイリアスだった，など。


Locationヘッダは新しいURIをポイントする。
bodyは301同様。


304 (Not Modified)
クライアントが既にそのデータを持っていることを示す。
条件付きHTTPリクエストと併用される。


Dateヘッダは必須。
ETagとContent-Locationは200の時と同じものを設定すべき。
Expires,Cache-Control,Varyは，以前に送信したものから変更されている場合には必要となる。
bodyはない。


305 (Use Proxy)
あまり使わない。
クライアントが特定のproxyを利用する必要があることを示す。
そういうケースがあまりないからあまり使わない。


LocationヘッダはproxyのURIをポイントする。


306 未使用


307 (Temporary Redirect)
リソースが別のURIにあり，再送する必要があることを示す。


GETの場合は303と同義。ミラーサイトへ誘導したい場合など。
POST,PUT,DELETEの場合はサーバが何かしらのアクションを起こすことになるので303とは意味が違う。


303なら正常終了したがbodyがないことを示す。
処理後のリソースが欲しければクライアントは新しいURIにGETを送る必要がある。


307は，サーバが処理を実行しようとすらしていないことを示す。
クライアントは新しいURIにリクエスト全体を再送する必要がある。

Locationヘッダは再送すべきURIをポイントする。
bodyは301同様。