ここ何か月か、Webサービスの設計について考えてます。次のエントリーがリンク集（ハブ）になっています。
うまくいかない点やら難しい点は次に書いています。
JSONデータをどうしたらハイパーメディアとみなせるのか
JSONベースのWebサービスを前提としたとき、困難の（全てではないが）一因は、JSONデータに対してハイパーリンクを定義する適切な方法がないことです。JSONスキーマの「ハイパースキーマ」という仕様案はあるにはあるのですが、2010年4月の段階ではイマイチでした。
JSONスキーマ仕様は現在ドラフト第3版となり、仕様としての精度は上がってきてます。
例えば、以前の minimumCanEqual / maximumCanEqual （よく分からなかった）が明確な exclusiveMinimum / exclusiveMaximum に置き換えられたり。
しかし、セクション6のハイパースキーマはやっぱり使える気がしません。僕が切実に感じている要求では、既に存在するJSONデータをハイパーメディアとみなす「みなし方」が定義できないとうまくないのです。
HTMLでは、ハイパーリンクと言えばアンカーとフォームを考えれば十分だし、そのマークアップ／構造／挙動は十分に定義されています。JSONでは、そのように強い標準はないし、単一の標準に収束する見込みもありません。
なぜ「みなし方」が重要か
外部から見たリクエスト処理の実行単位をアクションと呼ぶことにします。アクションはサーバー側に配置され、リクエストデータを入力としてレスポンスデータを出力します。アクションを引き起こすリクエストの発行基点をここではトリガーと呼びましょう。アクションから出力されたレスポンスデータは、クラアント側の状態となると仮定します。絵に描くと次のとおりです。
状態に埋め込まれたトリガーがハイパーリンクの本質です。別な言い方をすれば、トリガーを含む状態となりうるメッセージデータがハイパーメディアです。
すぐ上の絵では、トリガーからリクエストの矢印が出ているように描いてますが、実際にはソフトウェアが介在します。実際のHTTPリクエストを発行するソフトウェア部品をリクエスターと呼ぶことにします。トリガーがリクエスターの入力となってはじめてリクエスト発行が可能となります。
リクエスターを動かすには、ハイパーメディアの特定の部位をトリガーだと識別して、それをリクエスターに理解可能なデータとして渡さなければなりません。トリガー（ハイパーリンク）のマークアップ／構造／挙動が決まっているなら、リクエストの発行メカニズムをハードコードしても問題ありません。しかし、前節最後に書いたごとく「強い標準はないし、単一の標準に収束する見込みもない」となると、トリガーの識別と抽出・加工を行う部分をある程度カスタマイザブルにしておかないと対応できないのです。
リクエスターを何種類も作るのは避けたいので、ハイパーメディアと単一のリクエスターの橋渡しをする部分でトリガーフォーマットの差を吸収したいのです。
つまりは、与えられたJSONフォーマットの、どの部分にどんな形でトリガー（ハイパーリンク）が入り込むかを正確に記述する手段が必要だということになります。これはまさに「JSONハイパースキーマ」が目標としている機能性ですが、残念ながら使いやすくない。という次第で、致し方ないから「また考えてみよう」と思ってます。
