- API, UI as Commons
- http://subtech.g.hatena.ne.jp/miyagawa/20060509/1147161767
つまり、Amazon Web Services みたいな、「APIでデータとれるのでどうぞあなたのアプリでつかってください」っていうのが旧時代の Web API で、Amazon の場合はこれでも結局最後は集客につながるからいいんだけど、次の Web API ってのは逆で、「APIにあわせてアプリかけば、こっちのサービスで使えるようにしてあげますよ」ってやつ。こっちのほうがより「つながってる」感じがする。
例えば RSS でフィードを出すよう書いておけば、RSS を取り込んで Google パーソナライズに表示させるよう設定してもらうこともできるし、feedpath 等々のフィードリーダに取り込んでもらえるし、マッシュアップして何かおもしろいことをしてもらえるかもしれない。
RSS は標準的な規格の一つなんだから当たり前だ、とか感じてしまうかもしれないが、一時代前（といってもそんなに大昔ではなく、せいぜい５年前）からすると上記はとんでもなくすごいことだ。
でも、そうは言っても、今ではやっぱりもう「当たり前」のことなのだ。
こういったことを「当たり前」の前提としたときに、「次」はどうなるのだろう。
RSS が「アプリ」にスケールアップしたのが、上記引用での「次の Web API」。
例としてあげられている A9 等はフィードの延長として機能的になり、TypePad Widgets は今までもできたことがより簡単にできるようなっている。
「つながってる感」というのはなかなかすばらしい言葉だと思うが、その言葉の響きに対する期待値は、正直なところもっと高い。
例えば Widgets で妄想するなら、コンシューマの作った天気予報 Widgets と 別のコンシューマの作ったカレンダー Widgets を blog (Google Homepage でも可) にうまく貼り付けたら、連動してカレンダーに週間予報が出たり、過去の天気が表示されたりするイメージ。
もちろん「そう作ってあった」というオチ無しで、である。
荒唐無稽な話に聞こえる？
課題はあれこれ多いが、実現できる見込みはあると思っている。
具体的な課題としては、
- API 設計
- サービス提供形態 ( id:n_shuyo:20060702 にも関連 )
- 有為なサービスを個人が作成しても、大勢が利用するためにはサーバ資源が必要
- 有為なサービスを web で公開しても、外に漏らすことのできないデータには適用できない
- 「アプリ」と「リソース」と「サービス稼働サーバ」を独立
この２つをクリアすれば（まあ細かい課題は他にもたくさんたくさんあるだろうが）、少なくとも「天気予報 Widgets と カレンダー Widgets を貼り付けたら連動」くらいなら実現できると考えている。また、それができるなら他にも……と妄想をふくらませる余地ありあり。
