API, UI as Commons
livedoor readerのインターフェースだけを利用して、データソースを他のところにするというHackから、「API, UI as Commons」みたいなアイディアについて、盛り上がってるみたい。
この Hack が素晴らしい。で、見てておもったんだけど 、ウェブのフロントエンドアプリケーション作りが得意な人は、そのフロントエンドアプリケーションから利用するバックエンドの API を規定して、API のエンドポイントを任意の URL に設定できるとかそういうものを作ったりとか、そういう時代が来る。
んで、今回のハックはこれに似てるんだけど、Livedoor Reader がフル Ajax な UI を出してくれたおかげで、バックエンドを同じにするだけで、UI部分だけを再利用することができる。これは Ajax それに GreaseMonkey のおかげ。ちなみに Google Reader のフロントエンドも バックエンドの API をたたくJS で書かれている。しかもフォマットはフルAtom なので、Plaggerからこれのバックエンドをすげかえるのもできそう。
こうして図にしてみると、以下のようなアイデアが出てきました。
* データソースは、RSSやAtomフィードよりも知的な感じがする(ロジックが組み込まれるため)
* ユーザーが定義したデータソースもfeed的に扱って、データソースのランキングができると面白いかも (データソースはURIで一意に選択できるため、データソースをfeed的に扱うことは可能だと思います)
* 異なるドメインに配置されたデータソースにアクセスするためのGatewayをLivedoorで用意しなければならない (XMLHttpRequestではクロスドメインで通信できないため)
* Livedoorは、REST的なインタフェースとJSONの仕様書を、開発者向けに提供する
クロスドメインのJSON読み込みのところは、On-Demand JavaScript Loadでもいけるんじゃないかなと、ずっと思っている。特に、サーバ側にクロスドメインプロキシをおくようなことをするのだったら、そもそもRSSでよかったのではないかって思う。
また、GM_XMLHttpRequestをつかうにしても、GreaseMonkeyをみんながインストールするわけではないので、いつまでもGeek向けのサービスから発展しなさそうでいやだな（Livedoor Readerを使うような人は結構な確率でインストールしているのかも？？）
ただ、任意の他ドメインのJavaScriptを読み込ませるのは、きっとセキュリティリスクが伴う話なので、まあ一度サーバかませたほうがいいのかも。でもわたってきたJSONデータをすぐにJavaScript側でevalしちゃうなら一緒だね。
