このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

［参照用 記事］

URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか

雑記／備忘

一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。

最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。

  1. すべてのURLを列挙したい。
  2. すべての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は単なるキー文字列や引数データではなくて、サーバー側に永続的に存在している“実体”に対応して欲しいのです。無限個の実体は考えにくいものです。例えば、次のような対象物に対して、僕らは暗黙に／無意識に有限性の前提を置いています。

  1. ファイルシステム内に存在するファイル群
  2. データベースのテーブル内に存在するレコード群
  3. とあるAPIに含まれる関数群

列挙可能性＝有限性は、対象物達を確実に把握して管理する上で必須の条件でしょう。

すべてのURLを分類したい

「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」において、サーバー側の実体の大分類を試みています。実体には種類があります。URLを見てリソース（サーバー側の実体）の種類を推測できるように、URL文字列に種類・種別をエンコードすべきだ、とも思っています。

URL文字列にリソースの種類をエンコードする方法は、主に次の2つでしょう。

  • URLの拡張子によりリソースの種類を表す。
  • URLのディレクトリー（に相当する部分）によりリソースの種類を表す。

ここで種類と言っているのは、“共通の挙動”と“レスポンスとして返すデータのMIMEタイプ”の組み合わせです。変な連想をしない前提で、リソースの「クラス」と呼んでもいいかも知れません。1つのURLが、複数のクラスに分類されると何かとトラブルのもとになります*2。すべてのURLはただ1つのクラスを持つべきでしょう。

まとめると：

  1. 特定のWebシステムの特定時点において有効なURLは有限個であるべき。
  2. 有効なURLは、ただ1つのクラスに分類されるべき。

*1:リアルな例が「いっちゃってるURL」にあります。

*2:例えば、与えられたURLの挙動が予測できなくなります。「ソフトウェアにとって大事なこと： 正しさが判断できること」も参照。