前回,前々回と使いやすいURIの設計のポイントについて見てきました。今回も引き続き,使いやすいURIにするにはどうしたらいいのか,ということについて考えていきます。

 URIの使いやすさについては,いろいろと考える話題が多いのですが,ここで話題として取り上げるのは「ページをリソースとして考える」ということについてです。リソースとは,そのまま日本語に訳せば「資源」という意味になります。

 リソースという言葉はいろいろなところで使われています。例えば「これだけの仕事をこなすにはチームのリソースが足りません」といったときには,人的資源というか,そのチームが持っている作業可能量のようなものを意味しています。コンピュータのリソースといえば,処理を行うために必要なメモリー量とかCPUパワーとか,もしくはネットワークの帯域などもリソースと呼ばれます。

 これらの例を見ると,リソースは「限りある資源」という感じで,有限のものをいかに有効に使うか,うまく配分するか,といったイメージがあります。しかし,「ページをリソースとして考える」という時のリソースは,ちょっと違います。この場合のリソースとは,「情報資源」,つまり簡単に言うと「データや情報のカタマリ」という意味です。ウェブ上には,様々な情報が公開されています。それらをページ単位で見ると,それはなにがしかの情報のカタマリであるとみなせるわけで,それがリソースなのです。そして「ページをリソースとして」考えたとき,URIはそのリソースの位置を表す住所であるわけです。

 ウェブ以外の情報資源としては,例えば書籍があげられるでしょう。それぞれの書籍には,みな情報が詰まっています。ありがちな例ですが,ウェブを図書館にたとえると,ページは個々の書籍になるわけです。そしてURIは,その本が何階にあるか,どの書架にあるか,といった位置情報に当たると言えますよね。

 今回の記事の趣旨を文章で言うなら「サイトを構成するURIが示すページは,みんなリソース,つまり情報のカタマリであるということを強く意識してサイトやURIを設計する」という感じになります。あくまで立ち位置というか見方の話ではあるのですが,その思想が使いやすいURIに結びつくんじゃないか,という話をしたいというわけです。

そもそもウェブページはリソースである

 ここでまずポイントとして,「ページをリソースとして考える」ということは,決して後付けで提案された考え方ではありません。そもそもウェブページは「リソースである」という考え方で作られたものだ,ということがあります。

 ウェブの仕組みは,1990年当時,欧州原子核研究所(CERN)にいたTim Berners-Lee氏によって生み出されました。そもそもの目的は,CERNの科学者が発表した論文などの情報資源を管理するためのものでした。今でこそウェブページは様々な目的に使われていますが,ウェブページはもともとリソースとして作られ,URIはリソースの場所を表すものなのです。

 URIという名前自体が生まれたのは,ウェブの誕生からしばらくたった1994年のことです。URIは「Uniform Resource Identifier」の略であり,リソースを識別するためのものであることが名前からもはっきりしています。

 とはいっても,ウェブページはリソースなのだから,そう使うべき,そうでない使い方は間違っている,というような原理主義的な考えを押し付けようとかそういうつもりは全くありません。ただ,そういう思想で設計されたものであるからこそ,それを念頭においてサイトの構築を行うことで,よりわかりやすくなる部分もあります。なので,そのことを知っておいて損はない,と思っているわけです。

 「ウェブページ=リソース」という考え方を念頭に置くと,URIの設計もおのずと変わってきます。リソースは「情報のカタマリ」という,いわば物ですから,それをあらわすには名詞が適しているはずです。この連載の第20回で「URIに動詞を使いたくなったら注意したほうがいい」ということについて触れました。その理由は「アーキテクチャや内部のシステムに関する情報がURIに含まれるべきではない」ということでした。それは,URIがリソースの場所を表す,ということを考えてもやっぱりおかしいことです。リソースをあらわすのに名詞が適当だとすると,URIは,その「内容」をあらわす名詞で表現したほうがいいということになります。

 繰り返しになりますが,例えば以下のような二つのURIを見比べてみてください。

 http://www.example.com/view?data=accessreport&year=2006
 http://www.example.com/accessreport/2006

図1●URIがVIEWという機械の場所っぽい
図1●URIがVIEWという機械の場所っぽい

 どちらも一見して,どこかのサイトのアクセス・レポートか何かのページだな,ということは何となくわかります。前者のURIは「view」という動詞が入っていて,パラメータとして「accessreport」を渡しています。結果としてそのURI全体としてはアクセス・レポートを表示するURIとなっているわけですが,「アクセス・レポート」というリソースの場所を表す住所としてどうなのか,という視点で見ると,ちょっと違和感があります。リソース自体の場所を示しているというよりは,「accessreport」という名前を入れるとアクセス・レポートというリソースをポンと返してくる「view」という機械の場所,という感じもしますよね(図1)。

 そして後者は,前者よりもずっと「リソースの場所」と言うには適したURIになっていますよね。動詞はなくなり,「accessreport」という「data」の場所,という感じがするURIになっています。


URIを変えない努力

 続いて,「Hypertext Style: Cool URIs don't change.」という,Tim Berners-Lee氏本人が書いたドキュメントの内容を取り上げて,考えていきたいと思います。これは「クールなURIは変わらない」というタイトルで日本語訳も公開されているので,読まれた方も多いのではないでしょうか。

 このドキュメントでは「一度決めたURIは変更すべきではない」ということについて,その理由やよくある失敗,そして問題解決へのアドバイスが述べられています。ウェブページがリソースである,という話のはずなのに,何でURIを変更すべきではない,という話をいきなりしだしたのか,と思われるかもしれません。が,このドキュメントは読んでみると「ウェブページがリソースである」ということを前提にして書かれていて,URIを「リソースを現す場所」としてより適切な設計にすることで,URIを変更しなければならない危険をより回避しやすくなる,ということが述べられているのです。

 さて,そもそも何でURIは変更すべきではないのかといえば,それは古いURIを使ってそのドキュメントにアクセスしようとした人が,アクセスできずに困ってしまうからです。どこかのページから張られたリンクをたどったり,検索エンジンの検索結果で見つけてアクセスしようとした時に,「Not Found」と表示されたり,そのサイトのトップページに飛ばされてしまった,という経験はきっと誰でもあるでしょう。

 情報の収集をウェブに依存していると,リンクをたどっても目的の情報にたどり着けない,という事態は結構頻繁に起こりますよね。そしてこれは,あまりいいことだとはいえません。特に検索エンジンの結果は,結果ページで内容がちょっと読めるくせに,アクセスするともうない,という状態になってしまい,その寸止めっぷりはかなりストレスがたまります。ウェブの世界はハイパーリンクで接続されたリソースのネットワークですから,リンク切れはその重要な要素を破壊してしまう行為で,それは極端に言えばウェブの世界観を破壊してしまう行為なのです。

 …とまではここには書かれていませんけれど,そこまで大げさにならなくても,普通に使っていても,リンク切れにであうのはあまりうれしくないですし,あるサイトにアクセスしたらリンク切ればっかりで「あそこはアクセスしてもリンク切ればっかり」とか「検索エンジンであのサイトが引っかかってもNot Foundばっかり」という印象を受けてしまったら,あまりそのサイトに行きたくなくなるものです。

 そして,リンク切れを起こす,つまりURIの変更を起こさないようにするための方法として提案されている内容を読むと,「ウェブページをリソースとして考える」ことと「リソースの分類を考える」ことの2種類に分けられると思います。

 URIの変更の大きな理由の一つとして,サイトを構築するアーキテクチャの変更があります。例えば利用する言語を変えたので「.do」から「.php」に変わりましたとか,そういう類の変更です。こうしたアーキテクチャに依存する文字列がURIに含まれていることがよくない,という話は前回,前々回と解説してきたURI設計のルールにも含まれていました。URIをリソースの場所と考えるなら,リソースの内容とそれを配信するアーキテクチャは本来関係ないですから,入れる必要はありません。そして,そうしておけば,たとえどれだけシステムを変更しても,同じURIに同じページをマッピングすることができそうです。

 とはいっても,ページの内容は同じであるにもかかわらず,URIを変更したい場合はやっぱりあります。それはページのカテゴリわけや構成などを見直して,データの整理したい場合です。こちらの場合は,「分類情報をURIから排除することで対応せよ」とこのドキュメントは述べています。例えば以下のようなURIのリソースがあったとします。

 http://www.example.com/topic/computer/javascript

 これは,おそらくJavaScriptに関する何らかの情報が載ったページだと思いますが,「computer」という分類に属したページのようです。だけどその後,プログラミング関係のページが増えてきたので,「programming」という分類に直したいなあ,なんて思うかもしれない,というような感じです。