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

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

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

参照用 記事

ハイパーリンク設計をサーバーサイド設計に従属させるべきではない

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

昨日の記事「ハイパーリンクは何を繋ぐのか」の続きです。今日も落書きみたいな絵で説明します。昨日使った絵も再掲(流用)します。

僕にとっては、ハイパーリンクがリソース間のリンクだというモデルは受け入れがたいものです(それが昨日の記事の主張)。サーバーは利用者の相手はできません。利用者に機能性や利便性を提供する窓口はWebクライアントです。利用者(それが人間だとして*1)は、画面を見て、アンカーをクリックして次の画面に移り ……、とナビゲートされます。このとき、URLの綴りや発行したHTTPメソッドを意識しているでしょうか? 「URL」「HTTPメソッド」という言葉を聞いたことがない人でも「画面を見て」「アンカーをクリックして」「次の画面に移る」ことはできます。

極論すれば、「URLの綴りや発行したHTTPメソッド」がなんであったとしても、画面に含まれる情報とナビゲーションが適切に設計されていれば、利用者は機能性や利便性を享受できるのです。もちろん、だからといって「URLの綴りや発行したHTTPメソッド」がどうでもいいとは言いません。考える順序として、クライアントの状態遷移が先行し、それを実現する手段としてサーバー側のメカニズムが従うでしょう、ということです。

昨日の記事では、クライアント側の状態遷移の例として、やたらに単純な直線状の絵を使いました。

もうちょっと入り組んだ有向グラフ、例えば次のような図のほうが一般性があるでしょう。

状態遷移を表す点線矢印の真ん中あたりに黒い棒を付け足して描き直すと、次のようになります。

黒い棒(塗りつぶしているのは単に目立つように)は、ペトリネットの用語法ではトランジション・ノードです*2。このトランジション・ノードに対応するナニモノカはサーバー側に存在します。そのナニモノカが、アプリケーション(クライアント側)状態の遷移を引き起こす駆動力なのです。

上記のナニモノカを僕はアクション(より正確には、アクションのエントリーポイント)と呼んでいます。アクションは、URL(のパス部分)だけで識別されるわけではありません。発行したHTTPメソッドやクエリーパラメータの一部もアクションを特定する目印に使われるかもしれません。HTTPリクエストから具体的なアクションを引き当てる行為を、リクエストのルーティングとかディスパッチと呼びます。

Webシステムのサーバー側機能は、公開されているアクションの集合により規定されると言ってよいでしょう。それぞれのアクションは、クライアント側状態を遷移させる働きを担います。そのことを図示すると次のようになります。

アクションの集合(ときに膨大)が何の脈絡もなく配置されていては使いにくいでしょう。なんらかの編成原理が必要です。その編成原理となるのがリソースという概念です。アクション達がてんでんばらばらに散在するのではなくて、リソースに付随すると考えます。「モノ」であるリソースを中心に「働き」であるアクションがグルーピングされます。リソースを黒丸で描けば次のような感じ。

昨日描いた絵(下図)も、リソースを黒丸で付け加えていました。

「リソースが“オブジェクト”で、アクションが“メソッド”」と言えば、多少はオブジェクト指向っぽい説明にもなります(いつも注意しますが、こういうアナロジーに過度に拘ってはいけません)。リソースのURLがオブジェクトIDで、アクションを識別するHTTPメソッド+αがメソッドセレクター、といった対応です。

そうなると、リソースの“クラス”概念も欲しくなります。「URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか」で言及した「有効なURL(リソース)の分類」がクラス概念の話です。

クラス概念の一番簡単な実現方法は、URLの拡張子にクラス名をエンコードしてしまう方法です。このとき、.php だの .jsp みたいな実装を識別する拡張子はダメです。意味的な分類に対応する拡張子を使うことになります(「RESTfulなWebサイトと拡張子を含むURLについて」参照)。拡張子による方法は、さすがに単純すぎて利用場面は限定されますが、リソースのクラスという概念を理解するには適切だと思います。


クライアント側の状態遷移からはじまって、アクション、リソース(のインスタンス)、リソースのクラスなどを説明しました。この説明の順序がクライアント側からサーバー側への順序であったことに注意してください。これが自然な順序だと思うのです*3

*1:人間ではない利用者でも、本質的な事情は同じです。

*2:白い丸は、ペトリネットではプレース・ノードと呼びますが、ここでは今まで通り「状態ノード」と呼びます。

*3:既存のWeb APIがあり、それに合わせてクライアントを設計するときは逆順になります。しかし、もとのWeb APIの設計者はクライアント側の状態遷移を想定すべきでしょう。