実際にサンプルコードを書いてみたところ、このアプローチって設計・コーディングが面倒くさい割には実際のメリットはさほど大きくない気がしてきた。どうしてもサーバーサイドでのテンプレートを主にしたければ、JavaScriptでもサーバーサイドで展開された結果をそのまま利用した方が手っ取り早いかも。

Ajaxにおいては、クライアントが必要なデータをサーバーから直接（HTMLパースとかせずに）取得できるということが重要なのであって、それをどのような仕組みで対人間向けのフォーマットに変換するかはさほど重要ではない。あるいは、その仕組みの部分の汎用性に凝ることのメリットはそれほど大きくない。

そこでテンプレート展開以降についてはこだわらず、データ取得以前の部分にだけこだわって、次のような方針を考えてみた。

• まず基本的な内部設計として、サーバーサイドのデータ取得ロジックは、APIとして公開することを意識したインターフェース設計にする（多少冗長でも）
• インターフェース設計のポリシーとして、http://example.com/path/to/resourceで通常のブラウザ向けのHTMLが得られる場合
  • http://example.com/path/to/resource?__mode=rdfでRDF（XML）形式のデータが得られる
  • http://example.com/path/to/resource?__mode=jsonでJSON（JavaScriptコード）形式のデータが得られる
  • http://example.com/path/to/resource?__mode=htmlで部品利用向けのHTML形式のデータが得られる

なんて感じでどうだろう。

最後の部品利用向けHTML形式のデータというのが、サーバーサイドでテンプレート展開したデータをそのままJavaScript側で利用するパターン。JavaScriptで複雑なデザインを組み込む・メンテするのが面倒な場合はこれで対応。逆にJavaScriptコードからの操作性を向上させたい場合は2番目のJSON形式を主に利用。RDFは汎用あるいはRSSリーダー（RSS 1.0互換）用って感じ。

なんて感じでデータの読み込み側はそれなりにきれいに表現できるかなーと思いつつも、もうちょっといじっていたらまた気が変わるかもしれない。

ちなみに現在迷っているのはデータの書き込み側の仕組み。読み込みと同様にブラウザ向けHTMLと同じURIに対して、?__mode=jsonとかつけて渡す（POSTする）と、書き込み結果（成功・失敗。あるいはもっと詳細なエラー情報など）がJSON形式で返るようにしようかと思ったりもしたんだけど、ブラウザからの書き込みの場合は結果が文字列で返されるパターンよりも、結果に応じてリダイレクトしたりするパターンの方が多そうなんだよな。基本的な挙動が違う処理を呼ぶのに同じURIを使うのは直観的じゃない気もしてきた。書き込み系処理に関しては、API専用URIを別に割り当てた方がいいのかな？