続・多言語リソースのURIに関する覚書
昨日の日記の最後にこう書きました。
正規URIに対してリクエストがあった場合、サーバは英語とスペイン語、どちらでレスポンスを表現するか決めなければなりません。Accept-Language ヘッダを見てもよいのでしょうが、それだとコンテントネゴシエーション方式と紛らわしいので、デフォルト言語をあらかじめ決めておいてもよいのではないか、と個人的には考えています。
この段落を書きながら、実は「なんだかおかしいな」とも感じていました。今日、違和感の原因が分かりました。
違和感の原因その1：プラトニック形式のURIのみ提供？
『RESTful Webサービス』の「4.6.1 表現の選択」にこうあります。
コンテンツネゴシエーションと呼ばれる方法もある。この場合は、プラトニック形式のURI（http://www.example.com/releases/104）のみが提供される。このURIへのリクエストを送信する際、クライアントは受信したい表現の種類を知らせる特別なHTTPリクエストヘッダーを送信する。
しかし、「コンテントネゴシエーションではプラトニック形式のURIのみ提供される」というのは、著者独自のやり方ではないでしょうか。
分かりやすいので「セマンティック Web のためのクールな URI」の例を引きます（一部修正しています）。
GET /people/alice HTTP/1.1 Host: www.example.com Accept: text/html, application/xhtml+xml Accept-Language: en, deサーバーは次のように応答するでしょう。
HTTP/1.1 200 OK Content-Type: text/html Content-Language: en Content-Location: http://www.example.com/people/alice.en.html
ご覧の通り、プラトニック形式と非プラトニック形式のURIを提供しながらコンテントネゴシエーションできるわけです。
「4.6.1 表現の選択」では、各言語にURIを割り当てる方式とコンテントネゴシエーション方式が別物として扱われていますが：
ことも可能ということです。
違和感の原因その2：デフォルト言語を決めるべきか？
冒頭に引用した段落に書いたとおり、プラトニック形式のURIがリクエストされた場合にどの言語で返すかを決めるには：
- Accept-Languageヘッダを見る
- あらかじめデフォルトの言語を決めておく
という方法があります。昨日の時点では、後者のほうが好ましいと考えていました。Accept-Languageヘッダを知らないユーザも多いだろうし、知っていても変えるのが面倒なこともあると思ったからです。
しかし、デフォルトの言語を勝手に決めてそのリソースを返すのも、必ずしもユーザにとっては嬉しくないのではないでしょうか。少なくとも私がユーザだったら、表現可能な言語一覧を見て自分で選びたくなるかもしれない。
などと考えながら同書の付録を見ていると、「B.4.1 300（Multiple Choices）」が目にとまりました。これで上記の要求を満たせるのではないか。
そこで、このステータスコードの簡潔な説明例を引いてみます（一部修正しています）。
300 Multiple Choices
HTTPステータス・コード
要求されたURIは、2個以上のリソースを参照している。例えば、URIは複数言語に翻訳されているドキュメントを参照することができる。サーバによって戻されたボディ部には、正しいリソースを選択する方法に関してより詳しいデータのリストを入れることができる。
確かに、私の要求は満たせそうです。
