rebuildfm 35のAPIの話が面白かった

etc

Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)の最後の方のAPIの話が面白かったのでそれについて書いてみる。

HTTP JSON APIにしろHiveServerが提供しているようなThrift APIにしろバックエンドにあるAPIサーバーにクライアントがアクセスして情報を取得してそれをもとに画面表示するっていうパターンは多いと思います。ここでいうクライアントってのは別にPCブラウザに限らなくてiPhoneやAndroidのようなスマートフォンだったりタブレットだったりいろんなケースがありえます。

iPhoneアプリでトップページを表示するのにAPIを10回叩く必要があるとかだと、レイテンシの問題もあるし開発の手間も増えますよね。そうじゃなくてiPhone専用のAPIみたいなのがあればそれ1回呼べば済むのでレイテンシの問題もなくなってユーザーエクスペリエンス的にも良いです。でもじゃあそのAPI誰が作るんだよってのもあるし、デバイスが増えたらその分APIも増えてメンテナンスが難しいですよね。

APIには2種類あってジェネリックなAPIとクライアント固有のAPIがあります。今までは前者の話だけだったのが後者の話も出てきました。

従来だと

クライアント -> ジェネリックなAPI

のみだったのが

クライアント -> クライアント固有のAPI -> ジェネリックなAPI

というのも出てきました。ジェネリックなAPIもクライアント固有のAPIから呼ばれることにはなるでしょうがこの２つは同一LANでしょうし、レイテンシは少ないよねと。


そしてAPIを使う側からすると２種類のユーザがいます。

一つ目がlarge set of unknown developers (LSUDs) 、APIを使う不特定多数の開発者、イメージとしては例えばTwitter APIを使うTwitterクライアント開発者でしょうか。

二つ目がsmall set of known developers (SSKDs)、APIを使う、すでに知られた開発者、イメージとしては例えばクックパッドのiPhoneアプリ開発者でしょうか。ようはAPIを使う開発者が限定されているケースですね。

なおLSUDsとSSKDsという用語は
The Future of API Design: The Orchestration Layer
から来ています。

LSUDsに対してはジェネリックなAPIを提供せざるを得ないと思いますが、SSKDsに対してはもっとクライアント固有のAPIを提供した方がビジネス的にも良いでしょう。

ちなみにQuipperではクライアント固有のAPIを作って使っているようです。

こうして Backbone.js や Chaplin.js をベースに実装されたクライアント向けに最適化された API を提供できるようになり、クライアント側の実装をシンプルに保てたり、 HTTP リクエストの回数を減らしてパフォーマンスを向上させることができた。

例えば OSFA な API をやめる - @kyanny's blog

そして Netflixではクライアント開発者がgroovyを使ってクライアント固有のAPIを自分で実装してデプロイしているようです。すごいな。