API

【お知らせ】今後の新着情報は、はてなブックマークで更新していきます

Posted on 2月 6, 2008. Filed under: API |

2006年9月からusingapi.comにてWebAPIの最新情報をブログ形式で書いてきましたがこれ以降は、はてなブックマークで更新していく予定です。
はてなブックマーク – nob_funakiのブックマーク / API

コメントやサンプルレスポンスといった情報は付与できなくなりますが、参照していただければ幸いです。

APIに関するより詳細な情報源としてこちらも参考になるかと思います。
: Mashupedia – マッシュペディア – : Web API x Mashup

全文フィードを読む | Make a Comment ( None so far )

エンジニアから見たWebAPI 総まとめ 2006-2008年

Posted on 2月 5, 2008. Filed under: API |

2006年から2008年まで注目してきたWebAPIについて、エンジニアの立場から総括してみたい。

ここで言うエンジニアはウェブサイト制作に関わるプログラミングができる人のことである。WebAPIとはHTTPを介してフォーマット化されたデータをやり取りするサーバのインターフェイスを指し、以降略してAPIと書く。基本的に国内で無料公開されたAPIについて言及する。また多分に主観の入った意見が含まれている点はご容赦いただきたい。

おもちゃとしてのAPI

APIとはなんであるか、と聞かれて一言で答えるなら「おもちゃ」だ。

複数のAPIを組み合わせて1つのサービスにすることをマッシュアップと呼び、ブームになった。同時期に登場したAjaxによってウェブのインターフェイスデザインに変化が訪れ、つくる側は多くの新しいアイディアを考え出せるようになった。

APIは明らかに製品やサービスとは違う。エンジニアだけをターゲットとし、別の製品やサービスが作られることを目的としている。APIやAjaxといった新しいものに真っ先に飛びついてあれこれ作り出していった人たちは「新しいおもちゃが出てきた！」と感じていたように見受けられる。企業がおもちゃを提供し、それで遊ぶエンジニアがいる、という構造が初めて生まれたのではないだろうか。

APIの種類

少し立ち返って既出のAPIをいくつかの視点で分類してみる。
1つは内容による分類。

投稿系: ブログの記事投稿などに使われる。多くはHTTPのPOSTを用いてデータを送信するタイプ。
検索系: サーバ側にデータベースがあり、その情報をパラメータで絞り込んで取り出すタイプ。このタイプが最も多い。
変換/抽出系: サーバ側のデータを直接返すのではなく、与えられたパラメータを変換あるいは抽出して結果を返す。パラメータにURLを指定してHTTP経由でデータを取得してから結果を返すものもある。
制御系: JavaScriptのライブラリで提供される。GoogleMapsなど。内部的には検索系であることが多い。
認証系: ログインの機構を外部に持たせ、セッションを制御する。

2つ目は提供元の違い。公式なAPIに対して以下のような2タイプの非公式なAPIがある。なお2つとも個人的な呼び方で一般的ではない。

野良API: 公開を意図していないが第三者が利用できるもの。提供元がAjaxによる通信に利用している場合などに見受けられる。仕様は公開されていないので推測するしかない。仕様の変更はいつあるとも知れない。
勝手API: 個人が特定のサイトのHTMLをスクレイピングするなどして入手したデータに対して仕様を決めてAPI化したもの。取得先のHTMLの仕様が変わるとデータに不整合が生じるかもしれない。場合によっては著作権の問題が発生するかもしれない。

3つ目は入力フォーマットによる違い。

REST: 端的に言えばブラウザのアドレス欄ですべてのパラメータを表現できるAPI。通信は1回の送受信で完了する。実装のしやすさ、デバッグのしやすさで優れている。
それ以外: SOAP、XML-RPC、AtomPPなど。HTTPのPOSTを使い、比較的複雑な仕様で通信する。投稿系や認証系に多い。

4つ目は出力フォーマットの違い。先に挙げた検索、変換/抽出系に属する。

XML: RSSも含まれる。APIでは一番多く利用されているフォーマット。
JSON/JSONP: JavaScriptで標準的なデータの表現形式。
PHP Serialize: 米Yahoo!が最初に提案した。PHPのunserializeという関数でデータ化が容易なデータの表現形式。（参考：Using Serialized PHP with Yahoo! Web Services）
その他テキスト形式: プレーンテキスト、CSV、HTMLなどが考えられるが一般的ではない。
バイナリファイル: 画像や音声といったバイナリファイル。変換/抽出系に属するもので画像が多い。

200あまりあるAPIを俯瞰的に分類できそうなものを選んでみたが他にも面白い分類方法があるだろうか？
usingAPI;で取り上げた各APIにこれらの分類をしてこなかったのが悔やまれる。ある程度出揃った今だから考えられる分類なわけだが、今から分類し直す手間は惜しい。

使えるAPI、使えないAPI

APIにも使いやすいものとそうでないものがある。使えるAPIを一言で表すならば

「APIの提供側が予想しないようなものがつくれる」

である。最も使えるAPIは今のところGoogleMapsだと思うが、MapsのAPIを使ってGoogleの予想もしなかったマッシュアップが登場しているはずだ。検索系のAPIで提供側のデータの色が濃過ぎると、提供側のサイトを超えられないサイトしか作れない。また、1日のアクセス数を大幅に制限したり、取得できるデータ量を減らしたり、指定できるパラメータが貧弱では大した使われ方はしない。提供側が保守的になればなるほど、予想する範囲の使われ方しかされず、最終的には使われない寂れたAPIになるだろう。

使いやすさでは、まずREST。ユーザ登録が必須なのもやりづらい。マッシュアップの観点では同じジャンルのAPIが複数出ている場合が使いやすい。食べログ、ホットペッパー、ぐるなび、とレストラン情報を返すAPIが揃っているのでマッシュアップするのはたやすい。あとは、緯度経度を返すAPI同士。GoogleMapsとのマッシュアップになりがちだが、地理情報でつなげるのはわかりやすい。

そのAPIが使われているかどうかは、マッシュアップがどれだけされるか以外に公開後ライブラリがどの程度登場するか、でもわかる。PHP、Ruby辺りでAPIを制御するためのライブラリが登場するものは人気があると言えよう。

ところで、APIは多くの場合「ベータ版」と称して実験中であるからバグがあるかもしれないし、サービスがいつ停止するかもわからない、と謳っている。だが、動作しないままで放置するのはいかがなものか。APIの名前をあえて挙げることはしないが、アクセスするとjava.lang.NullPointerExceptionを吐いたりAPIのURLがNot Foundだったり出力されるXMLがパースエラーを起こしていると、とても残念である。

コンテスト

APIとセットでよく登場したのがマッシュアップサイトのコンテストである。盛り上がりを見せたコンテストもいくつかある。特にAPIを提供する企業を増やした、という意味でもサンとリクルートによるMash Up Awardの存在は大きい。

コンテストを開催する側の意図としては

知名度の向上
トラフィックを集めるマッシュアップを作ってもらう
エンジニアとの交流

が考えられる。受賞式が開かれて記事になっているコンテストは概ね成功しているのではないだろうか。

海外のコンテストは賞金より賞品が多い。賞金総額はまちまちだがMash Up Award以外は1社単独の開催で100万円以内といったところ。

応募作品数は、ユーザの主催者企業への愛着と賞金総額を掛け算したもの、で算出できそうだ。応募が少ないと結果発表がひどく寂しいものになってしまう。APIをたくさん出しているにも関わらずコンテストを開いたことがないのがはてなとlivedoor。コンテストなぞ開かなくてもユーザの愛着だけでたくさんAPIを利用される、という自信だろうか。

コンテストの参加者にはプログラムを書くのを本職としていない方も多く見受けられた。作品を応募する方の多くがブログに書いているのでそれを追っていくと参加者層が見えてくる。主催者の意向が色濃いかもしれないが、コンテスト参加者のインタビューが載っている記事もある。
MA3応援座談会 -つくるぶ特集

コンテスト後の受賞式には過去2回参加したことがある。自分の場合、エンジニア同士の交流は積極的に行いたい質なので2回とも楽しめた。主催者側としても社外のエンジニアと交流するいい機会になっているのかもしれない。

マッシュアップコンテストが今後も開かれるかは微妙だ。ブームが去った感はある。マッシュアップに限定すると作品の幅が狭すぎるきらいがあり、コンテスト向けに作るサービスは一過性で閑古鳥が鳴きがちである。応募作品をよりアート寄りにしていくか、アフィリエイトと同じようにAPI経由のトラフィックから表彰する、といった転換が必要に思われる。

企業とAPI

企業が出すAPIには企業のイメージが色濃く出る。
まずAPIを出すタイミング。早かったのは

はてな
Yahoo! JAPAN
livedoor
リクルート

ビッダーズのようにブームが来る前から公開していた企業もあれば単発でAPIをリリースした企業もあるがその後も継続的にAPIを出し続けたのは上記4社であろう。失礼ながら意外だったのがリクルート。コンテンツにお金をかけて保持している企業ほどAPIでオープンにするのを拒みそうなものだが早い段階で出してきた。この後、大手ではカカクコムや楽天が続いた。

大手以外ではゴーガはMash Up Awardで受賞してから頻繁に名前を見るようになった。

APIは当然のことながら誰が出しても同じようなインターフェイスになる。多数の会社が全く同じサービスを出すことは少ないだけに比較しやすく、センスの差が出る。どういったところに表れるかというと設計の美しさだろう。データ構造をいかにわかりやすく的確に表現するか、複数のAPIを出すのであればその統一性、あるいは世界的な標準仕様を取り入れているか、など。XMLの要素名1つ1つにセンスの良し悪しを感じるかどうかは人それぞれだろうが、気になる人は気になるはずだ。

APIを出すにあたって企業の本気度も様々である。Google Labsを端に発する「ラボ」ブームでAPIを公開するのと一緒にラボを設立する企業が多く見られた。ラボもブログでも同じことが言えるが、更新頻度でコストのかけ具合が見て取れる。更新しなくなり寂れてしまうぐらいなら設立しない方がいいように思われる。

エンジニアのコミュニティ形成には各社苦戦しているようである。Yahoo!JAPANや楽天のコミュニティサイトでも参加者が少なく、議論が活発に、とは程遠い。もともと囲い込めるタイプのユーザではないのかもしれない。

APIのターゲットユーザはエンジニアである。ネット企業にとって、エンジニアから見たイメージをよくし、採用に結びつけることは重要なはずだ。APIの公開はリクルーティングの一環とも言える。この効果を数値化するのは難しいだろうが、各社どの程度の効果があったのか気になるところ。とはいえ、APIを使って開発する層はごく少数であり、新卒採用に好影響をもたらす程の効果があるかは疑問である。

またAPIを公開し、使われることでサイトのトラフィックを増やし、収益に結びつけるのも大きな狙いである。しかし残念ながらAPIの公開で大きくトラフィックを伸ばした例を聞かない。

現状ではAPIを公開しないデメリットも存在する。「Web2.0」の先進的なイメージに対して「Web1.0」というレッテルを貼られたくない、という動機でAPI公開に踏み切った企業も少なくないだろう。一度公開してしまうと止めにくいサービスだけに、赤字垂れ流しになっていないことを祈るばかりだ。

今後

マッシュアップの面白さはデータとデータを組み合わせて新しい価値のあるデータにすることにある。今までオープンになっていなかった、ネットからアクセスできなかったデータが多く出てくればより面白いマッシュアップが生まれるだろう。ネットから遠い業種ほど面白そうだが、その分APIでデータを公開するメリットが薄いかもしれない。

すでに大きなトラフィックを持ったサイトが公開するAPIは大きな影響力を持つ。先のAPIの部類で言うと認証系が期待できる。Yahoo!あるいはmixiの認証APIはユーザによりよい使い勝手をもたらすだろう。

新しいAPIの登場頻度は2008年になって若干落ちた。しかし、はてなやlivedoorといった企業は新しくリリースするサービスに適当なAPIがあればこれからも公開し続けるだろう。公開する前提で作った新しいサービスであれば開発コストは低く抑えられる。APIを出すことが一般化しつつあるので、今後はサイトを音声認識に対応したりW3Cの定めるHTMLに対応するのと同じレベルで、RSSやAPIを出すことになっていくものと思われる。

全文フィードを読む | Make a Comment ( None so far )