Hatena::ブログ(Diary)

naoyaのはてなダイアリー

February 28, 2006

疎結合のための Web API

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

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

KoshigoeBLOG: 内向き API と外向き API

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

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

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

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

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

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

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

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

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

AnthonyAnthony 2006/02/28 14:10 はじめまして。
いつも楽しく読ませていただいています。

疎結合というキーワードに惹かれてコメントさせていただきました。
システムのメンテナンス性や拡張性を考えると疎結合で構成することが望ましいのでしょうが、現場では場当たり的なチューニングで密結合で作ってしまうことがありますね。

もうすでに読んでおられるかもしれませんが、私はキム クラーク著「デザインルール」を読んで疎結合の重要性を理解しました。
疎結合なくしてオープンなシステムの発展はありえないですからね。

jkondojkondo 2006/02/28 15:34 自動的に外部公開APIが整備される、というのも大きいと思う。

y_o_u_1y_o_u_1 2006/02/28 20:16 感覚的に「物理的なもの(この場合DB)に直接アクセスするのは無しだよな〜」って思いながら設計していたんで、それって疎結合って言うんですねぇ。

DBの場合I/Fは固定ですが、APIだったらそれを包含する形で自分で定義するんで、そういう自由度って言うか、それも重要でしょうし。

って、こういうシステムの考え方、って、オブジェクト指向プログラミングに近い?かな。I/Fを決めて、それのみでアクセスをするから個々のオブジェクトは守られるし、システムも破綻しないし。って。DBがオブジェクトの変数として。