こんなURI設計、どう？

先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。

設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。

以下、第15章に掲載されているURI例で違和感の原因を探ってみます。

郵便番号リソースのURI

http://zip.ricollab.jp/1120002

これは違和感ありません。

検索結果リソースのURI

http://zip.ricollab.jp/search?q=小石川

ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。

いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、クエリパラメータの有無で「郵便番号としてのsearch」なのか「検索結果リソースのパスとしてのsearch」なのか判別できます。

が、これが郵便番号検索サービスでなかったらどうなのか。また、クエリパラメータの有無でリソースが劇的に変わるのは非直感的なのではないか。そう感じるわけです。

地域リソースのURI

http://zip.ricollab.jp/東京都

違和感はここで頂点に達します。今後「東京都」という郵便番号や「1120002」という都道府県が現れることはないでしょうが、文字の並び方でリソースが劇的に変わるのは非直感的なのではないでしょうか。「シンプルでない」といいかえてもよいです。

こうしたらすっきりするのでは

そこで考えました。そもそも「東京都」は郵便番号ではなく都道府県名です。であるならば、下記のようなURIがふさわしく思えます。

http://area.ricollab.jp/東京都
あるいは
http://ricollab.jp/area/東京都

地域データのキーであることが分かりやすくなるためです。

ちなみに「/」を階層構造を示す記号と捉えるならば『「area/東京都」って何やねん』という気もしてきます。そう考えると、前者のようにサブドメインを「area」にしたほうがしっくりきます。

検索結果リソースは、下記のようなURIがふさわしく感じられます。

http://ricollab.jp/zip_search?q=小石川
あるいは
http://search.ricollab.jp/zip?q=小石川

郵便番号リソースと誤解されずに済むからです。

まとめ

以上をふまえ、データのキーを含むURIについては、サブドメインを切ったほうがシンプルなのではないかと思っています。

検索結果リソースのURIは、必然的に、サブドメインを切らないか「search」サブドメインを切るかのいずれかになります。

http://zip.ricollab.jp/東京都
http://zip.ricollab.jp/search?q=小石川

が

http://area.ricollab.jp/東京都
http://ricollab.jp/zip_search?q=小石川

または

http://area.ricollab.jp/東京都
http://search.ricollab.jp/zip?q=小石川

になるということです。

サブドメインを変えることで、認証処理やセキュリティ周りに影響があったり、SEO的にまずかったり（詳しくないので知りませんが）といったデメリットがあるかもしれません。

とはいえ、文字の並びやクエリパラメータの有無でリソースを判別する必要がないのは、実装上のメリットです。ルーティング処理が単純になるからです。

以上、叩き台エントリでした。