APIが有効なケースとそうじゃないケース

Ryosuke Iwanaga
2 min readNov 2, 2013

--

Web2.0なんてのが流行語になった時代、いろんなところが自分が持ってるデータをAPIを通じて誰もがアクセスできる様にして、利用者はいろんなAPIをくっ付けることで新しいサービスができる、みたいなのが面白いと思った。

ユーザが更新をするようなデータや、どちらかというとRPCに近いようなものはAPIとして提供すると大変世界が平和になる。Twilioとかすごいよね。

ただ、なんでもAPIにすりゃいいかというとそうじゃない。

特にreadが中心のデータ、例えばスポーツの過去の記録だったり、法令だったり、アニメの放映日だったり。こういうのはみんなが思い思いに更新するわけじゃないし、そもそも更新頻度が低いわけで、そのデータを使ったサービスを作る時に都度APIアクセスしてたら無駄だし、API側もリクエストが無駄に多くて余計な制限をかけることになる。

こういうデータは、たとえデータがそこそこデカくても全部丸ごとダウンロードしてもらって、検索は自分達のデータベースにロードして勝手にやってね、の方がお互いにハッピーだと思う。更新があったらどっかに通知が出て、利用者は最新データをダウンロードするか、または差分だけダウンロードできたら十分。

ちょっとカッコつけて、自分が持ってるデータにイケてる検索インタフェースをつけたところで、ほぼ間違いなく利用者のニーズには合致しないので、利用者はスクレイプして全件取得するようなバッチを書いちゃうわけ。お互いに時間の無駄じゃない?もしかしたら誰かがとってもクールなインタフェースを作ってくれるかもよ?

たぶん問題になるのは更新時にみんなが一斉にダウンロードにきちゃうこと。OSXの最新版は5GBくらいあったらしいけど、みんながドッとダウンロードに押し寄せてもまぁなんとかはなった。Appleのインフラがあってこそではあるけど、世の中にはCDNというのもあるので、Appleじゃなくてもそこそこはいけるんじゃないかな。

こういうマスタデータ的なものはXMLでもJSONでもなんでもいいから構造化したテキストにして、gitのレポジトリにしちゃってGitHubでホスティングしたらいんじゃない?といつも思ってる。

なんかこういうフレームワーク無いのかな。

--

--

Ryosuke Iwanaga

Software Engineer / ex-AWS / #FTTB / Anime / Canada -- Posts are my own, not endorsed by any org. Request 1on1 here: http://calendly.com/riywo/1on1