疎結合のための Web API

RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。

以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB　な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？

違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。

二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもないですよね。

すると、いつかこういうことが起こります。

• A サービスのデータベースに直接つなぎにいく B サービスを作る。
• A サービスの担当は B が A のデータベースを使ってることを知らない。
• A の担当がデータベースの構成を変更する。例えばパーティショニングとか。
• データベースの構成が変わってるので、当然 B が落ちる
• あわてて B のサーバーでライブラリを update する
• (酷いときは、ここで他のライブラリも一緒にあがって依存関係とかで他のライブラリも必要になって芋蔓式に色んなところがボロボロになることもあるｗ)

A と B の粒度がどのぐらいかにもよるけど、ほんのちょっとあのサービスの情報使いたいなあぐらいの気持ちで DB を直接叩いてるときほど、こういうことが起こりやすい。「まさかあのサービスが、こっちのデータベースを叩いてるなんて思わなかった」という具合。

たとえばはてなダイアリーのメンテナンスをするのに、いちいちはてなラボのアプリケーションとか気にかけるのはめんどくさいですよね。

あと、はてなSNS は Rails で作ってあって、はてなダイアリーは Perl だから、その二つの間でデータベースの抽象化を共有できない。

この辺の理由から、 Web API を使うと疎結合になっていいわけですよ。Web のインタフェースは変わりにくいけど、内部の構造っていうのは四六時中いじりまくって変化しまくりですから。パブリック & プライベートの話も、外から RSS 取ってる分には、ウェブに見えてるものが見えてる分にはパブリック、見えてないもんに関してはプライベート、という風に切り分けられるからミスは出ないですよね。

ちなみに、失敗(?) と書かれているけど、失敗だとは思ってませんよ。フィードのキャッシュの扱いは、他のアグリゲータのサービスとかと同じですから。