RestNamingIssue

以下のトピックで一つ書くこと＞自分

REST のキーであるリソースのグローバルネームスペースへの同化は諸刃の剣
プログラミングでいう「隠蔽」とはコンテキストやネーミングが不動ではない、ということを前提にして発展してきている
一方、ウェブの空間ではこのような不動性はかなりの幅で崩れが許容される（いわゆるリンク切れ）、その一方で不動性は「CoolUriDontChange?」などで「よい」リソースの重点事項の一つとされる
リソースをグローバルなウェブ情報空間に解き放つことは価値がある
また、クローズドな空間で利用する場合も、柔軟かつ強力なネームスペースによる情報管理という思想は価値がある
しかし、もし SOAP-RPC や XML-RPC など RPC 風の使いかた以外がないような話であれば、伝統的な隠蔽を優先した方がソフトウェアとしての「かっちり度」（頑健性とまではいえない）は上がるかもしれない。名前空間により力を与えるということは、その裏に隠れる処理系にはそれなりのコストがかかる。
つきつめると、散々議論されてきたように、やろうとしていることが messaging なのか methodcall なのかということになる。ウェブは情報空間だから messaging により力が与えられる。しかし、methodcall が否定されるわけではない（"Web" Service ではないだけで）。

ここでサンプル：

あるユーザーのプリファレンスを管理する RESTful WebService があったとする：

 http://example.com/path/to/user/xyz12345/preference

これが動的に処理されるとして、このプログラムはどのように「どの」ユーザーかを判別するか？もちろんURIだ。しかし逆に言えば、プログラムはこの特定のURIの形式に依存していることになる。他の原則の一つには「URI is opaque」というのがあり、URIはあくまでグローバルネームスペースにおける識別子であり意味のある情報を見出してはならない（結合が強くなり loose coupling の障害になる）というのがあるが、これと干渉を起こしている。

そしてもう一つの issue は、URI はある存在の representation を得るための locator だということだ。つまり、ある同一の存在の representation を返す URI は複数あってかまわない（"relation between URI and represented object is many-to-many"）。しかし、上のサービスは opacity が弱いので、別の URI になり呼び出しコンテキストが変わると正常に稼動しない。いってみれば relocatability に乏しいのだ。

これを回避するためにはネーミングではない out-bound な経路でパラメータを渡す必要があり、そうすると

 http://example.com/path/to/preference?user=xyz12345

みたいなことになる。URI は opaque なんだから表記が違っていてもネーミングに入っているのではないかって？たしかにその通り。しかし、現実の実装的には後者の方がなぜか（というわけでもないが）容易なのだ。どちらも REST だが、やりやすい REST とそうでないのがある。

 ここはさらにアクセスコントロール、URI^HL は階層表現だが階層構造を
 意味しない、とか、Web as a filesystem とかと絡められればいいが、
 たぶんうまくまとまらない。

たしかに REST でも GET parameter は safe method へのパラメータとして特別とされる。HTTP の呼び出しで渡せる物を method, query, parameter の三つにわざわざ分類しているほどだ。そういうわけで、query は naming でありながら parameter でもあるという二重性が（本質的ではなく実装や慣習的にだとしても）ある。この "query magic" が効いているということなのだろうか？

 ああ、さらに message body を自己完結させようとすると naming や query と
 重複するというのがある…全部をどうやってまとめるか要考慮

もちろん、これは捉え方にもよる。上は preference オブジェクト（ウェブなので OOP 的な意味とは違うが）という存在を中心に考えているが、

 http://example.com/path/to/user

という UserManager? オブジェクトがあって、それが xyz12345/preference を食っているのだ、と考えればこのレベルで relocatability はあることになる。しかし、実際にプログラミングを重ねていくと、この見方と現実の環境（ツールやプラットフォームで上の URI をどのように扱っているか）にはやはりちょっとしっくりこない。このミスマッチをいかにうまく解消しつつリソースを提供するかが RESTful APIを実装するときのポイントの一つになると思う。

ただ、言える事は

 POST http://example.com/endpoint
 Content-Type: application/rpc-methodcall
 
 <getUserPreference><user>xyz12345</user></getuserPreference>

よりは、参照可能性の分だけは情報としての存在価値が間違いなく、そしてはるかに高いということ。これは「プリファレンス取得」という methodcall ではなく、「プリファレンス」という情報。だから RESTful にマップすることでより多くの価値を得られる。

ウェブサービスを提供したいのなら、アプリケーションの処理に着目してサービス設計をするのではなく、登場するリソースとその間の関係に着目しなくてはならない。いかにアプリケーションのデータモデルをウェブ空間にマップするか、それがキーになる。

脱線：

ウェブページや（人間用）ウェブサービスの世界ではリンク可能性が極めて重要なポイントになっている。リンクできない物は検索対象にならないし、そもそもウェブに存在していないのと同じくらい価値が低いとみなされる。逆に、リンクを（する｜される）ことはより多くの情報伝達機会を結果として生み、それがすべての経済価値に直結してきた。このウェブの原理は（機械用）ウェブサービスにとってどのような意味を持つのだろうか？

ある人は無償かつ大規模にウェブサービスを展開することは技術上の興味の対象にはなっても、経済的なメリットがないから dead end になると主張する。曰く、商品情報を流しても価格を機械的に比較・選別されるだけだからメリットがない、などだ。しかしこれは一面的な見方に過ぎない。この比較・選別はいまの（人間向け）ウェブサービスでも起こっていることだ。それでウェブが dead end かというと全然そんなことはない。

本当のウェブサービスのポイントは「特定の情報を」機械処理できる点ではなく、複数の、従来であれば引き合わせられることがなかった情報とコンテキストの組み合わせが生み出される素地になる点に尽きる。情報への広範なアクセスと機械処理のパワーによる強力な横断的処理によって単体で存在していたよりも価値のある組み合わせがより多く生み出される。

この価値は絶対的なものではないし、価格比較ほど単純なものでもない。その特定のコンテキストにおいてより高い価値があるということだ。もちろん、より多くのコンテキストにおいて高い価値を維持する商品というものはあるだろう。この競争にコストに見合わないほど負ける商品であれば最終的には市場から退出することになる。しかし、これはウェブサービスの問題なのだろうか？機械向けであろうと人間向けであろうと、より多くの評価機会を受けられることによる販売機会の増大という「機会の窓」の存在に価値を見出すと思うのだ。いまウェブサービスで先行している Amazon.com や Google は、そこに自らのビジネスチャンスを見て先回りを図っている。

最新の30件