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

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

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

参照用 記事

ハイパーリンクは何を繋ぐのか

[追記]
この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの(僕が推奨する)方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。
[/追記]

『RESTful Webサービス』という本はよく参照しましたし、このブログ内でも何度か言及・引用しています。

RESTful Webサービス

RESTful Webサービス

Amazon

この本はたいへん勉強になりました。しかし、多少の違和感が残る、なんか不足を感じる点もあります。この本の著者達、リチャードソン&ルビーと僕のあいだで、どこかに認識やメンタルモデルの食い違いがあるみたいです。それは(仮にあったとしても)微妙な点なので、なかなか明文化はしにくいものです。

最近また『RESTful Webサービス』をパラパラと見ていて、「アレッ?」と思ったフレーズがあったので、その周辺を紹介してみます。幾分かは、僕の違和感/不足感の説明になるでしょう。

内容:

アプリケーション状態

まず、アプリケーション状態という言葉ですが、95ページに「クライアント側で維持される状態」と定義されています。具体例による説明は次のようなものです。

検索エンジンを使用する際、現在のクエリと現在のページはアプリケーション状態である。この状態はクライアントごとに異なる。あるユーザーが「クラゲ」の検索結果の3ページ目を表示していて、別のユーザーが「ネズミ」の検索結果の1ページ目を表示しているとしよう。ページ番号とクエリが異なるのは、両者がアプリケーションで異なるパスをたどったためだ。それらのクライアントに格納されるアプリケーション状態はそれぞれ異なる。

「現在のページ」もアプリケーション状態の一部のようなので、「アプリケーション状態=画面+クッキーデータなど」と考えればよさそうです*1。僕はそのような理解をしてます。もちろん、「画面」という概念がないなら解釈に修正が必要ですが、クライアントが「利用者に同じ情報を提供し、利用者の操作に同じように反応するなら、同じアプリケーション状態にある」と言っていいでしょう。

接続性

『RESTful Webサービス』の100ページで「アプリケーション状態エンジンとしてのハイパーメディア」(Hypermedia As The Engine Of Application State)に少し触れた後で、この言葉より「接続性(Connectedness)」という言葉を使うよ、てなことが書いてあります。

リンクを持つという特性を、接続性(Connectedness)と呼ぶことにする。Webサービスは、ユーザーがリンクをたどり、フォームに記入するだけで、サービスを別な状態へ移行できる範囲まで接続される。これを「接続性」と呼ぶのは、「アプリケーション状態エンジンとしてのハイパーメディア」と呼んだのでは、概念が実態以上に難しくなってしまうからだ。筆者が言いたいのは、リソースをそれらの表現において相互にリンクすべきだということである。

最後のほうにある「リソースを相互にリンクする」ということが、僕には不自然に思えます。なぜなら、ハイパーリンクによりリンクされる対象はリソースではなくてアプリケーション状態だと思っているからです。

もともとの「アプリケーション状態エンジンとしてのハイパーメディア」の「状態エンジン」とは、「アプリケーション状態の遷移を引き起こす駆動装置」という意味ではないのでしょうか*2。「クライアント側のアプリケーション状態」を「サーバー側のリソース状態」にいつの間にかすり替えているように思えます。

具体例

具体例で話しましょう。

僕(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 の画面を再び眺める。「うん、これでよし。」

アプリケーション状態≒画面 と考えると、4つのアプリケーション状態があり3回の遷移が生じています(途中でリダイレクトをはさむとかの議論は省略)。アプリケーション状態を白丸、遷移を点線矢印で描くと次のようです。

このアプリケーション状態遷移には、当然にサーバー側のメカニズムが関与しています。アプリケーション状態を表す白丸以外に、その状態遷移を引き起こすサーバー側のナニカを棒のような四角形で描きましょう。ちなみに、この図示法はペトリネットと同じです。ペトリネットでは丸をプレース、棒をトランジションと呼んでいます。

ペトリネット風の図示法を採用すると、アプリケーション状態のあいだの遷移は次のように描けるでしょう。

棒(細い四角形)のそばに書き込んであるラベルはHTTPメソッドと動詞(「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」を参照)です。

  1. 「HTTPメソッドGET + 動詞view」で状態1から状態2に遷移
  2. 「HTTPメソッドGET + 動詞edit」で状態2から状態3に遷移
  3. 「HTTPメソッドPOST + 動詞save」で状態3から状態4に遷移

4つのアプリケーション状態と3回の状態遷移のあいだ、相手にしているサーバー側リソースは http://hiyama.example.com/blog/entry123 だけです(黒丸がそれ)。アプリケーション状態の遷移をリソース間のリンクとは考えにくいです。

ハイパーリンクは何を繋ぐのか

アプリケーション状態とリソースをノードとして、リクエストの辺とレスポンスの辺で繋ぐと、有向二部グラフができます。中間のノードを省略して描き直せば、アプリケーション状態の遷移グラフとリソースのリンクグラフとなります。これらは、ある種の双対とも言えるので、どちらか一方の情報から他方の情報を推測することはできます。

だから、“ある程度”は相互に変換できるとも言えますが、「ハイパーリンクはリソースのリンクだ」と言ってしまうと精密さを失います。『RESTful Webサービス』で採用している立場は「リソース指向」と銘打っているので、「サーバー側の状態=リソース状態」を中心に考える、ということなのでしょう。ですが、僕は「クライアント側の状態=アプリケーション状態」を中心に考えるべきだと思っているので、そこらへんで食い違いが出てるのかもしれません。

*1:実際に目に見えているビジュアルとしての画面というより、画面を識別するデータという感じでしょうが。

*2:原典にはまったく当たってないので、単なる憶測です。