改造しやすいURIにする
「改造しやすいURI」というのは，英語では「hackable」と表現されています。これは，URIを削ったり，文字を一部変えたりすることで，目的のページにアクセスできるURIにしよう，という意味です。例えば，以下のようなブログ・サービスのURIがあったとします。
http://blog.example.com/entry/2007/04/20
これはおそらく，2007年4月20日に投稿された記事の一覧ページではないかと想像できます。それでは，2007年3月3日に投稿された記事のページにアクセスしたいとしたら，どうしたらいいでしょうか。
おそらく一番簡単なのは（そのURIに気づいていれば，ですが），URIを以下のように書き換えることです。
http://blog.example.com/entry/2007/03/03
このように，URIを書き換えることで，自分の読みたいリソースに簡単にアクセスできるURIが，「hackable」なURIです。「hackable」にするには，「法則性を簡単に見つけることができる」ことが大切そうですね。
同様に，例えば2007年4月の記事の一覧は，こんなURIじゃないかと予想できます。
http://blog.example.com/entry/2007/04
でも，もしそうでなくて実は月別の記事一覧が以下のようなURIだったらどうでしょうか。
http://blog.example.com/entry/2007/04/monthly
これは，最初の日にち別のURIからはちょっと思いつきづらいので，hackableじゃないですよね。
そしてこれは，「URIがサイトの構造を表すこと」にも関係してくることですが，URIを削っていって，上位の階層にアクセスできるようにしたほうが使いやすいといえます。
例えば以下のヘルプページに検索エンジンからアクセスしてきて，そこからヘルプのトップページに移動したいとします。
http://blog.example.com/help/post-entry
真っ先に思いつくのは，以下のURIじゃないでしょうか。
http://blog.example.com/help/
ぱっと思いつく，ということはわかりやすい，ということですよね。したがって，おそらくヘルプのトップページはこのURIでアクセスできるべきなんだと思います。
こんな感じで，上位の階層に行くためにURIを後ろから削っていった経験は無いでしょうか。もちろん，ページ内にパンくずリストなどを使って階層をリンクとして示したり，そうでなくてもトップへのリンクはあるべきです。しかし，ページがすごく長かったりするなど，そうしたリンクを探すよりも，URIをちょっと書き換えてアクセスしたほうが便利な場合もあります。検索エンジンから階層の深いページにアクセスして，上位の階層に上がっていこうとしてURIを書き換えたところ，「Forbidden」や「Not Found」「ページが見つかりません」なんて表示されてしまうことがあるのですが，これはちょっと残念だと思います。
ちなみに，このようにURIを削って上位の階層に移ることを「Well Designed Urls」では「Peel-able」と表現していました。peelは皮むき器のことを「ピーラー」と呼ぶように，「皮をむく」という意味です。皮をむくように，URIを削っていく，という意味で，面白い表現だなあ，と思います。
クエリー文字列と使いやすさ
続いては「クエリー文字列を使わない」という項目についてです。クエリー文字列（query string）は，URIの中で「?」の後ろにつけられた項目です。例えば以下のURIでは，「name=copyright」の部分がクエリー文字列です。http://www.example.co.jp/help?name=copyright
クエリー文字列を利用すると，サーバー側のプログラムにパラメータを簡単に渡せるため，とても便利です。例えばCMSなどで，各ページに名前を振ったり，IDをつけたりして，以下のようなURIで各ページにアクセスするようなものもよく見かけます。
http://www.example.co.jp/view?name=index
http://www.example.co.jp/view?cid=12623
こうしておけば，「/view」にアクセスがあったときに呼び出されるプログラムが，クエリー文字列をチェックして，そこに書かれたnameやcidといったパラメータを元に表示するコンテンツを決定すれば済むからです。
でも，クエリー文字列は使うな，ということなのです。それ理由を，「Useful URLs」の「Useful URLs Omit Query Strings」という章では以下のように述べています。
- 見た目がよくない
- 覚えづらい
- URIが無意味に長くなる
- プログラムの内部構造がばれる
- 正規化しづらい
- 検索エンジンとの相性が悪い
最初の三つは明らかで，例えば以下の二つを比べると，2番目のほうが短くて，見た目にすっきりしていて，覚えやすいのは明らかです。
http://www.example.co.jp/view?name=help
http://www.example.co.jp/help
どちらも，おそらくヘルプページのURIであることはわかるのですが，上のURIは，「view」なんて言葉が入っていて「ユーザー中心のURI」では無いうえに，nameというユーザーから見れば必要の無い文字が入ってしまっています。
4番目の「プログラムの内部構造がばれる」というのも，文字どおりです。上のURIの場合は，「ああviewというプログラムにhelpっていうパラメータを渡してページを表示しているんだなあ」ということが，すっかりばればれです。これは，「ユーザー中心の設計」のところでも述べたことですが，内部の構造をURIに含める必要はあまり無いですし，「じゃあhelpの部分をほかの文字に変えたらどうなるの？」という気持ちをユーザーに与えてしまうこともあるので（一部のユーザーでしょうが），あんまりうれしくない感じです。
続く「正規化しづらい」という点ですが，「正規化」とは記述のゆれを統一し，同じリソースを表すURIを同じ表記に統一することを指します。正規化では，「../」といったディレクトリの移動を表す表記を展開したり，そのほか相対パスを絶対パスに戻したりといった作業を行います。しかしクエリー文字列の中は，いわば受け取ったプログラムだけが理解できるブラックボックスのようなものになっているので，一般的なURIのルールでは解釈ができないため，正規化を行えません。
例えばアプリケーションによって「data=&name=index」のようなクエリー文字列があったとき，「data」というキーは空になっています。これが「name=index」のようにdataを取り除いてしまっても同じ動作をするのか，それとも違うのか，といったことはアプリケーションでのデータの扱いによって違ってきてしまいます。正規化ができないと，同じリソースを表すURIが複数可能になってしまい，URIの「同じリソースは同じURIで」という思想に反してしまう，ということなのだと思います。“URIの思想”に関しては，次回もう少し考えてみたいと思っています。
最後の「検索エンジンとの相性が悪い」について考えてみましょう。検索エンジンはクエリー文字列が含まれているページを嫌う傾向があるため，クエリー文字列を多く含むページは検索エンジンで拾われづらくなります。それは，クエリー文字列は正規化が難しく，中身がちょっとでも書き換わると異なるページとみなさざるを得ないからです。ほかに，文字を書き換えるだけで無限のURIが生成されてしまう可能性があり，検索エンジンのデータに悪影響を与えやすいことや，同じサーバーに対してクエリー文字列がちょっとだけ違うURIとして大量にアクセスを行って，負荷を上げてしまう危険性がある，といったことも理由として挙げられます。
最近はクエリー文字列が使われていても，検索エンジンで検索可能になることが比較的多いのですが，それでもクエリー文字列を含まないページに比べると，検索エンジンでの扱いは悪くなります。検索エンジンがどう扱うのかは使いやすさとは直接は関係ない気もしますが，検索エンジンからの流入はサイトのアクセスに大きく影響しますから，これも大事なファクターだとはいえますね。
また，Wikipediaでの記述で知ったのですが，クエリー文字列（Query String）は，URIの仕様を定めたRFC3986ではQueryと呼ばれていて，「階層で表せないデータを含む領域」として定義されているんですね。したがって，複数の順不同なデータをどうしても含まざるを得ない場合にはクエリー文字列を使う，といったことが「Useful URLs」の「Useful URLs Omit Query Strings」に書かれています。
そこには以下のような例が掲載されています。
http://example.com/map?lat=51.30N&lon=0.30W
これはどうも地図を表示するURIのようで，緯度と経度を指定しています。確かに緯度と経度はどちらが先ということもないので，こうした場合は階層構造は作れません。
しかし，このサンプルを見ていてもう一つ思ったことは，クエリー文字列を使うのに最も適しているのは，パラメータを変えるだけで，無限にページが生成されてしまう場合です。上記の地図の場合も，おそらく緯度と経度をちょっと変えれば，どんどん新しいページにアクセスできてしまうわけです。
ほかに，検索エンジンの検索結果もクエリー文字列を使いますが，こちらも検索後を変えれば無限にページが生成されてしまいます。検索エンジンに限らず，フォームを使った場合には，勝手にクエリー文字列として渡されるということもありますが，その場合も，入力されたデータによって作成される結果は無数に出てくる可能性がありますよね。検索エンジンは，無限にページが生成される危険性から，クエリー文字列を含むページを特別視していますが，それと同様，無限にデータが生成されるケースでは，クエリー文字列を利用するのは悪くない，とみなせるかもしれません。
逆に，ページの数が限定されているような場合は，パラメータが階層構造を一覧していないように見えても，情報をきちんと階層構造に整理して，クエリー文字列を含まないデータにしたほうがよさそうですね。
