一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。
最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。
- すべてのURLを列挙したい。
- すべてのURLを分類したい。
すべてのURLを列挙したい
あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。
列挙する／100%把握するには、URLは有限である必要があります。URLが5万あっても10万あってもいいのですが、曖昧性無く確定した有限個であって欲しいのです。
例えば、計算をサービスするWeb APIがあったとして、2 + 3 を要求するために /calc/add/2/3 のようなURL*1を使うと、可能性として無限個のURLを許容します。計算できる数値範囲は有限でしょうが、概念的には無限になりえます。こんなURLは使うべきではない、と思うのです。代わりに次のようなクエリパラメータを使えばいいのです。
- /calc/add?x=2&y=3
- /calc/?op=add&arg1=2&arg2=3
URLが指すモノが手続きであるなら、その手続きへの引数はクエリパラメータかリクエストボディで渡せばいいのであって、URL（パス部分）にエンコードする必要性はありません。
僕の感覚では（感覚ですけどね）、URLは単なるキー文字列や引数データではなくて、サーバー側に永続的に存在している“実体”に対応して欲しいのです。無限個の実体は考えにくいものです。例えば、次のような対象物に対して、僕らは暗黙に／無意識に有限性の前提を置いています。
列挙可能性＝有限性は、対象物達を確実に把握して管理する上で必須の条件でしょう。
すべてのURLを分類したい
「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」において、サーバー側の実体の大分類を試みています。実体には種類があります。URLを見てリソース（サーバー側の実体）の種類を推測できるように、URL文字列に種類・種別をエンコードすべきだ、とも思っています。
URL文字列にリソースの種類をエンコードする方法は、主に次の2つでしょう。
- URLの拡張子によりリソースの種類を表す。
- URLのディレクトリー（に相当する部分）によりリソースの種類を表す。
ここで種類と言っているのは、“共通の挙動”と“レスポンスとして返すデータのMIMEタイプ”の組み合わせです。変な連想をしない前提で、リソースの「クラス」と呼んでもいいかも知れません。1つのURLが、複数のクラスに分類されると何かとトラブルのもとになります*2。すべてのURLはただ1つのクラスを持つべきでしょう。
まとめると：
- 特定のWebシステムの特定時点において有効なURLは有限個であるべき。
- 有効なURLは、ただ1つのクラスに分類されるべき。
*1:リアルな例が「いっちゃってるURL」にあります。
*2:例えば、与えられたURLの挙動が予測できなくなります。「ソフトウェアにとって大事なこと： 正しさが判断できること」も参照。
