『RESTful Webサービス』読んでんですよ。まぁあらかた読んだんです。いちばん気になっているのはリソースの設計の部分なんですが、これを URI にマップするときにどうにもうまくいかないものが出てきて、しかもまだ解消していないので、それを書こうと思います。（実際のコードのレベルでは「えいや」でルールを決めてしまいましたが。）

何が問題かというと、

• 順番も有無も任意に決められ、かつお互いに階層関係にないパラメータで決定されるリソースの URI へのマップ

です。

例えば書籍の中では、2値によって決まるリソースとして緯度、経度が出てきますが、このときはカンマで区切ることで一つの位置という情報を表現していました。（typo で ; になっているところが何カ所もありますが、カンマになっていないと意味が通じません。）

/Earth/43.9,-103.46/...

このパターンは

• 「緯度経度」の順番
• 緯度、経度ともに欠けることがない

であり、比較的単純にルールを決定し、URI にマップすることができます。

しかし自分の作っていたリソースが

• A, B, C の3つのパラメータを持ち、それぞれ意味が異なる
• 3つはそれぞれあってもなくてもよいが、全部ないとさすがに困る
• 個々のパラメータに階層関係はない

というもので、簡単に言うと従来の Web では

?a=VAL1&b=VAL2&c=VAL3

という query string で表現されるものです。無理矢理階層を割り当てて

/VAL1/VAL2/VAL3

としても、VAL2 は別に VAL1 に属しているわけではありませんし、順番が関係ないからと言って

VAL1;VAL2;VAL3

にすると、今度はこの順番が入れ替わると意味が分かりません。では順番を保持させるべく

VAL1,VAL2,VAL3

なのかというと、……何度も書いてますがこの順番には特に意味はありません。ただどれが何のパラメータなのかを判別するために順番を守ってくれないと困る、というだけのことです。

これは…そもそもリソースがなんだか分かっていないってことなんですかねぇ？

イメージとしては以下のように三次元の座標軸上で考えられるのかなと思っています。

• パラメータが1つの場合はその軸とそれを回転させた立体のデータ

• パラメータが2つの場合はその2軸で作られる平面のデータ

• パラメータが3つの場合は3次元上の1点

という感じで徐々にリソースが限定されていくような感じ。もちろんパラメータが本当に3次元を表現していて、それぞれ x, y, z なのであれば順番は自明ですが、実際にはこの順番が自動的に決定しないというものです。

これは、どう考えるのがよいのでしょうか？ やっぱリソースがなんだか分かってないのかなぁ？ 適当に順番決めてカンマで区切るのが無難なのかなぁ？ さすがにパスがないのはダメだけど、カンマ区切りのパラメータの一部がないのは問題ないからなぁ。デキのよくない、引数の多い関数を作るみたいな感じでちょっとイヤだけど。