安静な URL は次のようになります。
http://example.com/en/city/ボストン
http://example.com/de/stadt/ボストン
またはこのように:
安静な URL は次のようになります。
http://example.com/en/city/ボストン
http://example.com/de/stadt/ボストン
またはこのように:
REST API でよく推奨されるルールは、すべてのリソースが 1 つの URI を持つ必要があり、HTTP ヘッダーを使用してリソースへのアクセス方法や操作方法をネゴシエートする必要があるというものです。ただし、明確なリソースを構成するものと、そのリソースの単なる別の表現とは何かを正確に判断する方法については、議論の余地があります。
あなたの例では、各都市はリソースであると主張できますが、その都市に関するデータの翻訳は表現です。これは、HTTPヘッダーhttp://example.com/city/boston
を使用してロケールを選択し、URL を常に にする必要があることを示唆しています。Accept-Language
別の解釈は、実際には複数の API を提示しており、それぞれが全体的にローカライズされているということです。これhttp://example.com/en/
は、英語の APIhttp://example.com/de/
のベース URL であり、ドイツ語の API のベース URL であり、たまたま同じリソースへの同様のアクセスを提供しています。これは、2 つの API を同期しておく必要がなく、対象ユーザーに合わせて調整できることを意味します。http://example.com/de/stadt/Boston
具体的には、ドイツ語 API 内の URL の方が適切であることが示唆されます。
また、リソース自体の名前には、「都市」などのリソース タイプだけでなく、ローカライズされた同等のものがある場合があることにも注意してください。そのため、都市が実際にリソース タイプである場合は、http://example.com/en/city/Vienna
に対応しhttp://example.com/de/stadt/Wien
ます。これはきちんと人間が判読できますが、基礎となるデータ モデルに組み込むのは難しいかもしれません。
同じコンテンツをできるだけ多くの言語で表示するだけの場合は、URL からロケールを完全に削除し、コンテンツ ネゴシエーションに依存する Accept-Language
ことが、より「RESTful」なソリューションのように思えます。同じコンテンツや機能を必要としない英語とドイツ語の市場が別々にある場合は、URL をローカライズするのが理にかなっているように思えます。
RESTful URL のようなものはありません。両方の URI のセットは完全に有効です。サーバー側のフレームワークが処理しやすい方を選択してください。私の推測では、それは2番目になるでしょう。