7月10日のギークサロンは、RedCruiseを起業、CTOとして活躍されるなどの経験をお持ちで、Web APIに詳しい船木信宏さん (Facebook) にホストしていただきました (船木氏のブログ using API; はこちら)。 以下に、サロンの内容についてレポートします。



■よい Web API とは？
Google Maps, Flickr, YouTube, Amazon, Twitter など、現在ひろく使われている Web API。 7月のサロンで船木氏は、Web APIについてのさまざまな事例について、いけてるAPI／いけてないAPI、公開する／しないの選択のような話題に触れながら俯瞰的な考察を提供してくださいました。
まず、いけてるAPIの特徴。 分類すると投稿系 (Flickr, twitter)、 変換/抽出系 (SimpleAPI – ウェブサイトサムネイル作成、 Yahoo! JAPANルビ振り)、 制御系 (Google Maps; ウィジェット/Google Gadgetsなど)、 認証系 (Facebook; Yahoo! JAPAN)、 検索系 (Amazon) があります。 これらは、自分で用意するのが困難なデータ／ツールを提供してくれていたり、広く普及しているサービスについて独自のアクセス手段を与えてくれたりしているので広く使われています。
逆に いけてないAPIの特徴。 データを出し惜しみ (最初の10件だけとか)している、1日に使える回数が極端に制限されている (1日500回とか)、全文検索できない、XMLなのにデータが構造化されていない、無意味にSOAPを使っている (複雑)。 ひどいものは NullPointerException エラーや 404 エラーが返ってきたり。
もっと広まってほしい／発展してほしい API の例としては、国立国会図書館の Web API や、レガシーデータ (ネット化されていない情報)、レストランのリアルタイム空席情報、家電を制御する API などがあります。 一般に、アフィリエイト API は構築にコストがかかる場合が多いというが、使う側のモチベーションが上がるのでがんばって公開してほしいとの船木氏のご意見はもっともだと思います。
設計についての話題。 もともとのシステム設計がきれいなときはあまり手間はかからない (MVC であれば V と C を変えるだけ)。 面倒なのはデータベースがない場合や(HTMLだけで5～10年分とか)、スクレイピングが必要な場合など。 API の名前の付け方には、センスが要求される。 Web API をシステムの設計に取り入れると、HTTP経由にするオーバーヘッドはあるものの全体的にシステムを疎結合に設計できる。 並列／分散処理をつくる場合にも便利なのではないでしょうか。
■ Web APIを公開する目的は？
APIを公開する理由には、以下のようなものがあるでしょう。 ユーザーがAPIを使って作成したアプリがトラフィックを増やしてくれる (アフィリエイトなどを経由した売り上げ増も期待できる)。 社外エンジニアとの交流、人材募集。 ユーザーがライブラリを作ってくれる。ニッチなサイトの場合、APIを公開してUI各種はユーザーに開発してもらうという狙いもあり。 APIを公開しないと、 Web 1.0 的企業とのレッテルを貼られてしまうかもしれません。 ただ、API が何の役に立つかどうかは 作ってから考えるという人／企業もあるようです (たとえば、 twitter はおそらく最初は あまり用途を考えずに API を提供したのではないか、という意見も会場から出ました)。 理想のAPIというのは、提供側が 予想もしなかった使い方をされて 新しいアプリケーション (応用事例) がどんどんできていくような API なのでしょう。
API を公開するとき、社内で議論になりそうな話題に、データをクロール (全件取得) させることの是非があると思います。 データを転売されるような悪用は防ぎたいが、提供側の目的に沿った使われ方をして正しくトラフィックを返してくれるのであれば問題ないのではないでしょうか。
APIコンテストの事例も紹介してくださいました。 リクルートのコンテストは賞金100万円。 他に Yahoo! JAPAN、 価格.com なども。 船木氏ご自身も Mash up Award コンテスト (リクルート社、サン・マイクロシステムズ社) にて 1 度の受賞経験をお持ちです (船木氏いわく、コンテストで勝つコツは、「見た目」「マッシュアップ感」とのこと)。 ただしコンテストを開催するときは、閑古鳥が鳴かないように注意してくださいとのこと。