Hatena::ブログ(Diary)

winplusの日記 このページをアンテナに追加 RSSフィード

2012-07-22

URLは識別子であってリソースそのものではない

なにかが抜けている -- Webと関わる人間はどこにいる? - 檜山正幸のキマイラ飼育記 (はてなBlog)を読みました。またもや具体的に考えていますが、ご了承ください。

状態とリソース

まず、ブログの例を少し変更して、検討してみます。

僕(hiyama)が、http://hiyama.example.com/blog/というURLのブログを持っているとしましょう。次の操作をしたとします。

  1. http://hiyama.example.com/blog/の画面から、http://hiyama.example.com/blog/entry123 へのアンカーをクリック。
  2. http://hiyama.example.com/blog/entry123 の画面を眺めてから、編集ボタンをクリック。
  3. 編集画面で編集を行なってから、保存ボタンをクリック。
  4. 更新に成功したとのメッセージが表示されたので、http://hiyama.example.com/blog/entry123 へのアンカーをクリック。(※これを追加しました)
  5. 編集後の http://hiyama.example.com/blog/entry123 の画面を再び眺める。「うん、これでよし。」

この1.と5.とでは、同じリクエストを実行していますが、画面に表示されている内容は異なります。それぞれ、編集前と編集後になりますから。この意味では、1.と5.とは異なった「状態」にあります。しかし、この1.と5.を別のリソースとして取り扱うことは想定していません。1.と5.とは同じリソースであり、3.でリソースの内容が変更されたと考えます。URLはリソースの識別子であって、リソースの内容(状態)の識別子ではないのです。

接続性

さて、なにかが抜けている -- Webと関わる人間はどこにいる? - 檜山正幸のキマイラ飼育記 (はてなBlog)には以下のようにあります。

状態空間S以外に、リクエスト先を識別するIDの集合をXだとして、先に述べた「主体の行為」をもう一度書くと:

  1. Xの要素xを選ぶ。
  2. Vの要素vを選ぶ。このとき、任意の値を選べるわけではなくて、選んだxに応じた制約があるのが普通。
  3. 値vをxに送る。

このように、sにおいて選んだ (x, v) に対して次の状態s'が決まるというのが僕が考える「対話における状態遷移」のモデルです。

まず、この1.で、要素xとして任意の値を選べるわけではなくて、現在の状態点sに応じた制約があるのが普通で、この制約をハイパーリンクという手段で実現しましょうというのが接続性だ、と理解しています。sで選択可能なx1,x2...xnをハイパーリンクとしてsの表現(といってよいのかわかりませんが)の中に埋め込んでおき、これによって遷移をガイドする訳です。そして、sで選択可能なxの範囲は、列挙することが(現実的に)可能な範囲に収まると思います。

つぎに、3.で送信される値vはリソースの内容であり、それによってs'は変わらないと考えます。ブログの例でみたとおり、内容は変わっても同じリソースであるので、xが決まれば次の状態s'が決まると考えます(うーん、これを「状態」とよぶのは適切ではないかもしれません)。この立場からは、ハイパーリンクはリソースをつなぐ、ということになります。

そして、このようなリソースを接続するモデルでは、檜山さんのおっしゃる「対話における状態遷移」を記述できないでしょう。値vを完全に無視しているからです。しかし、このモデルだけでもアプリケーションは構築可能だと思います。なので、「1.そもそも、そんなモデルは必要ない。欲しがらなくてもいいんだよ。」ということになります。

トラックバック - http://d.hatena.ne.jp/winplus/20120722/1342963186