技術者視点のユーザビリティ考第21回 “使いやすいURI（URL）”の設計を考える（続編）
水野 貴明（みずの たかあき）
例えば，各ページのコンテンツをIDで管理しているCMSがあったとして，URIが以下のようになっていたとします。 http://www.example.com/view/23413 この場合は「23413」が，コンテンツのIDだとしていますが，このURIだけ見ても，何のページなのかさっぱりわかりません。このように，マジックナンバーをURIに埋め込んでしまうと，その番号の意味を知らないと，内容がわからないURIになってしまうというわけです。したがってこの場合は，コンテンツごとにきちんと意味のわかる名前を付けられるようにして，その名前をURIに含めるようにすればいいでしょう。 ほかにも，例えばユーザー登録が必要なページで，ユーザーごとのページを用意する場合，おそらく振られているであろうユーザーIDを利用するより，ユーザー名を使ったURIにしたほうが読みやすく，アクセスもしやすいでしょう。例えばこんな感じです。
http://www.example.co.jp/user/123456/ ユーザー名をURIに含めてしまうと，ユーザー名を変えた時にURIも変化してしまうことや，同じユーザー名を使えない，という問題点もあります。 もう一つ，こうしたIDを利用した場合に問題となるのは，そのIDを書き換えることで，隠されている情報にアクセスできる可能性があることです。例えば以下のようなIDでコンテンツを管理していることが見た目に明らかなURIがあったとします。 http://www.example.com/view/23413 こんなURIを見たら，「23412」や「23414」にどんな情報が入っているか，気になりますよね。別に，それらもすべて広く公開しているコンテンツであれば問題ないかもしれませんが，ページによってアクセスコントロールをしたいと思っているにもかかわらず，設定を間違えて公開されてしまっているコンテンツがあるとき（もちろんそういうものが無いのがベストではあるにしても），そうしたデータが「ばれて」しまう危険性が高まります。URIを改造しやすくするのはいいことですが，あてずっぽうでのアクセスがしやすくなるのは，あまりいいことではないですし。 また，こうしたマジックナンバーは，データベースのキーなどを埋め込む場合が多いと思います。それは，「データやシステムなどの内部構造をURIに埋め込まない」という視点からも，あまりいいことではないですよね。 とはいっても，大量のデータを管理する場合には，マジックナンバーをつけるな，といっても難しい場合もあります。例えばオンラインショップなんかがそうですよね。アマゾンにしても，楽天にしても，独自のIDを使って商品を管理して，それがURIにも表れています。こんな感じです。
http://www.amazon.co.jp/%E8%A9%B3%E8%A7%A3RSS~RSS%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E7%90%86%E8%AB%96%E3%81%A8%E5%AE%9F%E8%B7%B5-%E6%B0%B4%E9%87%8E-%E8%B2%B4%E6%98%8E/dp/4886487467 この場合，URIを見てもアマゾンや楽天の商品ページだな，ということしかわかりません。しかし，全商品に個別のURIを振る手間や（楽天の場合は，出店している各ショップの手間になるのかもしれませんが），それによってどれくらいわかりやすくなるかを考えると，難しいところかもしれません（アマゾンの場合は，最近商品名がURIに含まれるようになったのですが，日本語の場合はそのままではわかりません。この問題については次回触れたいと思います）。 アマゾンの場合は最近はURIにタイトルも入っているので若干ポイントが違ってきますが，上記のURIでは「4886487467」がASINコードです。ASINコードは，書籍に関しては昨年まで利用されていた10桁のISBN（国際標準図書番号）と同一で，これは標準的なコードだったのですが，今年に入ってISBNが13桁に変わったものの，アマゾンのASINコードは10桁のままなので，乖離が起こってしまいました。 また，コミュニティサービスでは，ユーザーIDが会員番号のような意味を持つ場合もあるようです。例えばmixiでは，以下のようなURIが使われています。 http://mixi.jp/show_friend.pl?id=（ID番号） これは聞いた話ですが，mixiのオフ会なんかにいくと，このID番号（入会時期が早いほど数が若い）に関する会話があったりするそうです。そうなってくると，ユーザーIDが表示されていることにも意味が出てきているんだなあ，と思います。
拡張子はコンテンツのデータ形式を表すようにする拡張子は，言わずとしれた，ファイル名やURIの最後に付く「.html」とか「.gif」「.pdf」といったファイルの形式を表す識別子です。Webサイト上で配布されるデータにしても，HTMLファイルの「.html」や画像の「.gif」「.jpg」，そのほかPDFの「.pdf」やPowerPointの「.ppt」など，様々なファイルの拡張子がURIに含まれています。これらの拡張子は，おおよそコンテンツのデータ形式を表しているものであり，今回問題としているのは，そうでないもの，例えば「.cgi」や「.php」，「.jsp」「.do」といった，システム側で動作するプログラムの形式などを表している拡張子です。これらは，システム側で，どのプログラムを実行するかを指定するために利用しているものですから，ユーザーにとって必要な情報ではないですよね。 そのアプリケーションがphpで書かれているのか，Javaなのか，なんてことは，URIからわかる必要ってあまり無いわけですし，しかもそのURIで配布されているデータがどんなデータなのかがわかりません。「.cgi」となっていても，アクセスしてみないとそれが画像なのかHTMLなのか，もしくはPDFなのかはわからないわけです。そうした拡張子の存在は，URIを長く，わかりにくくする上，「ユーザー中心の設計」ともいえない，というわけです。 サイト「Useful URLs」はもっと過激で，そのものずばり「Useful URLs Omit Filename Extensions」というページにおいて，ファイル拡張子は使うべきではない，と言い切っています。その理由として，長くてわかりにくい，利用しているアーキテクチャがあからさまにわかりセキュリティ的に危険，将来的なアーキテクチャの変更に伴ってURIが変わってしまう可能性がある，を挙げています。 同じリソースを表すURIは普遍であるべき，という考えについては次回改めて考えてみたいと思いますが，確かにこれまでphpで構築されていたサイトをリニューアルの際にJavaで書いたものに置き換えたから，同じページが「content.php」から「content.do」に変わりました，というのはちょっとわかりにくいかもしれない，と思います。 実際には，ブラウザはどんなデータが送られてきたのか，ということをHTTPのレスポンスヘッダーの中にある「Content-Type」で判断しますから，拡張子なんていらないといえばそうなのかもしれません。 ただ，例えば筆者はPDFファイルをブラウザ内でそのまま開くのが（時間がかかって）嫌いなので，拡張子がPDFになっていると直接クリックせずにダウンロードしています。そのため，拡張子が無かったらやりづらいなあ，と思います。ダウンロードしたファイルが，基本的にはURIを基にしたファイル名で保存されることを考えると，ダウンロードを前提としたファイルはきちんとデータ形式にのっとった拡張子をつけたほうがいいような気がします。 もちろん，サーバー側でURIとは無関係に，ファイルを保存する際のファイル名を指定することもできます。しかし，静的なファイルを配布するのに，わざわざそこまでこだわる必要も無いのではないでしょうか。ちなみにGoogleでは，「filetype:doc 文書」のように，ファイル・タイプで検索が可能です（図2）。これもURIの拡張子を見ているようなので，きちんと検索できるようにする意味でも，拡張子って必要だと思います。
図2●GoogleではURIの拡張子で検索できる このあたりをまとめると，HTMLを返すURI，つまりいわゆる「ウェブページ」を表すURIの場合は拡張子は無いほうがいいけれど，けどそれ以外のデータ，たとえばPDFやWord文書，それからXMLやJSONなどのデータは，データ形式を表す拡張子をつけるのが良い，ということになるでしょうか。
最後のスラッシュのあるなしでページを変えないこれはつまり，以下のような二つのURIが，別々のコンテンツになるような設計はよくない，ということを言っています。
http://www.example.com/blog たしかに，この二つが，例えば上は「blogとは何なのか」を表す説明ページで，下は実際のこのサイトの近況を知らせるブログ，といった状態だと，明らかに間違いやすくてよくない感じです。使いやすさ，アクセスのしやすさを下げている感じがとてもします。したがって，この場合は，どちらか一方のみを使い，他方にアクセスがあった場合には，リダイレクトで正しいURIに飛ばしてあげる，といったようにしてあげるといいのだとおもいます。
とりあえずの締めくくり前回，今回と，URIの基本的な設計思想といいますか，こういうURIはダメだ，的なルールについて，いくつかのサイトの情報をベースに考えてきました。ちょっと理想論的な部分もあるのかな，という気もしますが，こういうことをきちんと考えておくか，おかないかで，URIの設計もだいぶ違ってきそうな気がします。これらのサイトには，ほかにもいくつかのルールが例とともに紹介されていて，例えば「ドメインの最初のwwwは要らない」とか「スペルミスをある程度許容して，正しいサイトへ誘導するべき」といったことから，コンテンツを移動するな，というようなサイト全体の設計にいたることまで書かれています。もし興味があれば，チェックしてみてください。 次回は，今回の続きで，URIと日本語の問題や，RESTという考え方，そのほか実際のサイトのURI設計を見ながら，その使いやすさを紹介する，といった内容でお届けできればと思っています。
キーワード
|
|
||||||||||||||||