次の話

» Permanent link | |

blogger が落ちてたんで遅くなりました。

http://subtech.g.hatena.ne.jp/miyagawa/20060509/1147161767

http://naoya.g.hatena.ne.jp/naoya/20060509/1147157679

この Hack が素晴らしい。で、見てておもったんだけど、ウェブのフロントエンドアプリケーション作りが得意な人は、そのフロントエンドアプリケーションから利用するバックエンドの API を規定して、API のエンドポイントを任意の URL に設定できるとかそういうものを作ったりとか、そういう時代が来る。

大体近いんだけど、ちょっとまとめ方が違ってる。

(中略)

Amazon Web Services みたいな、「APIでデータとれるのでどうぞあなたのアプリでつかってください」っていうのが旧時代の Web API で、Amazon の場合はこれでも結局最後は集客につながるからいいんだけど、次の Web API ってのは逆で、「APIにあわせてアプリかけば、こっちのサービスで使えるようにしてあげますよ」ってやつ。こっちのほうがより「つながってる」感じがする。

このやり取りがこれだけの短時間のうちに行われているのがさすが miyagawa さんと naoya さんという感じ。 僕はこういう見方で Livedoor Reader を見ていなかったので、かなり感銘を受けた。 以下はそこから出た妄想です。

思うにこれからの Web サービスは三つに分離するのではないか。 ひとつは Amazon S3 や Google Base や Flickr や はてなブックマークのようなデータストア提供サービス。 二つ目は OpenID/Typekey 認証やはてブの件数取得 API や SimpleAPI のような機能提供サービス。 そして三つ目が今回の LDR のような UI 提供サービス。

データストア提供サービスというのはわかりやすいと思う。 これまではローカルに保存されていたようなユーザデータを Web 上にもってきて付加価値をつけて提供するサービスのこと。

これに対して機能提供サービスは基本的にデータは保持しない。 もちろん設定情報とか最低限は持つんだろうけど、あくまでもそれだけ。 ユーザの一番大切なデータの保管は他にまかせちゃう。 そのかわりにそこでしか提供できない機能を提供する。

んで UI 提供サービスを使ってそれらをマッシュアップするわけです。

こうなってくると、データストア提供サービスや機能提供サービスは、 固有の UI を持つかもしれないけどそれはあくまでもオマケで、 彼らの本当の価値はユーザデータの格納と各種機能の提供になる。 そして UI サービスは、 いかに汎用的かつ拡張可能な機能を持ち、 かつ洗練されたユーザインターフェースを作るか、 が勝負になる。 LDR は今まさにこの先頭を走っていて、そこにこそ価値があるのかも。

つまりはてブの編集フロントエンドに LDR がなったらすごくね、ということですね。今はまだ完全にはできないけど。 もっと言うと誰でも最速の人が作る UI を自分のサービスのフロントエンドエンジンとして使えるようになるということです。

あとは各サービス間のインターフェースが問題になるんだけど、 データストアの大本命は Atom Store (APP)でしょうね。 各データストアサービスは GData のように必要な拡張タグを施して Atom フィード/エントリを提供する。 UI や機能提供サービス側は共通タグにはもちろん対応するんだけど、 それ以外の拡張タグや microformats にも対応していく。 拡張タグに対応する UI 機能を pluggable に作る必要もありそうだ。

もちろん課題はかなりある。 たとえば現状では Greasemonkey がないとだめ。 しかもたぶん GM_xmlhttpRequest 使って別ドメインにアクセスすることになるんで、 セキュリティの問題がつきまとう。 これは cross-domain 対応の XMLHttpRequest の実装が揃うまで待つしかないのかな。 よく知らんけど

それから認証と SSO も。そこをうまくやらないと使ってもらえないし。

あと一番難しくてだからこそ希少価値があるのは LDR レベルの UI が作れるエンジニア(というかデザイナかな)かもしれない。流れはそっちだと思うんで、がんがれ若者