naoyaの日記

■ Web API フレームワーク 19:36

これはさっきの OpenSearch みたいな API の規定とはまた違ったレベルのイノベーションだとおもう。 Ajax UI がコモンズとして再利用できるみたいな。これについては本家Blogで、あとで書く。かも。

subtechグループ - Bulknews::Subtech - API, UI as Commons

即レスどうも。

まとめ方が違うって話だけど、僕の

というか RSS リーダー自体が実はそういう類のものなんだけどフィードだけだと実現できることが限定的なので、それをもう一歩進めてっていうのが OpenSearch。で、これからはよりプログラマブルな API を規定するアプリケーションが面白いということにおそらくたくさんの人が気づいたはずだ...とかね。

の「よりプログラマブルなAPIを」っていうのは「OpenSearch みたいなものよりも更にプログラマブルな API を」という意味で多分同じことを言ってるような気がする。そこはまあいいや。

フレームワークの話をもう少し。

こうなってくるとバックエンドアプリケーションはウェブに対してまず API を提供して、フロントエンドは必ずその API を使って作るというのが理想的になってくると思うんだけど、そういうアプリケーションを意識せずに書けるあるいは、クライアントプログラマにそれを制約として課せられるようなフレームワークが欲しくなる。

Catalyst の View::JSON とかは渡したデータ構造が勝手に JSON になって Web API になりますよ、というものだけども、これだけだとまだ開発者は「どういう API を持たせて、どういうデータ構造を返して」というのを自分で考えないといけない。なのでインタフェースに制約が欲しい。

このときに AtomPP の参照版みたいなのがあって、API がその制約で固定化されてるとフレームワークが作りやすいなと。要はインタフェースが決まってて、あとは中の実装をすれば OK みたいなことが Web API でもできる。でも参照に関するロジックというかインタフェースって、特定のドメインに密結合したような実装になりがちというか、汎用的な参照用インタフェースって何? みたいなとこがあって、なかなか難しい。

一度はてなでも、というか d:id:jkondo がすべてが Web API (AtomPP/REST) で公開されるフレームワークみたいなのを試しに作ったんだけど、抽象化のレベルをどこまでしなきゃいけないのかとかが難しくって実用的なレベルまで持っていけなかった。(API として公開できない情報をどう扱うかという話もあったっけ)

バックエンドはすべて Web API になってて、フロントエンドはそれらを組み合わせるっていう物を作る方法論がフレームワークになってくれると、バックエンドプログラマとインタフェースプログラマの分業がしやすくて結構幸せかもしれんなーと、20代前半のヤングな方たちがバックエンドのことしらないけど動的言語でバリバリいろんなものを作ってるのを見てると結構強く思ったりする。

RSSリーダーのようなツールとしての特色が強いものは JS で実装して、はてなブックマークみたいなドキュメント色の強いものは HTML で実装してとすれば検索エンジン云々というのもまあ別に関係ない。

Web API 前提フレームワークって結構いろんな人が考えてると思うんだけど、どういうアーキテクチャのものが考案されてるんだろ。