5分で分かるWebAPI
最近の記事
Web APIという単語が出てきたのはおそらく2003年頃で、Web 2.0という単語が広まってきた頃でした。元々その前進としてWebサービスがありましたが、そちらは主にエンタープライズ向けでSOAP（元々はSimple Object Access Protocolの略）を使ってデータの送受信を行うものが多かったと記憶しています。
Webサービスは主に企業間でインターネットを介したデータの送受信を期待して作られていましたが、構築時のコストに比べてメリットが少なかったり、利用までの敷居が高いこともあってあまり広まりませんでした。GoogleやAmazonもSOAPベースのAPIを提供していましたが、今はもうありません。
そんな中台頭してきたのがWeb APIになります。APIとはアプリケーション・プログラミング・インタフェース（Application Programming Interface）の略で、Webサービスをプログラミングから操作するための方法といった意味になります。Web APIは前述の通り、Web 2.0という単語が出てきたのに合わせて注目が集まりました。記憶を辿ると、最初はDeliciousやFlickrといったサービスがデータの取得だけでなく、投稿（ブックマークや写真を新規作成する）機能をWeb APIとしてリリースしたのが最初ではないでしょうか。その後、多くのWebサービスがWeb APIをリリースしはじめ、現在では新しくサービスを作る場合にはWeb APIを予め用意しておくものといった雰囲気さえあります。
フォーマットはJSONが基本
Web APIが出始めた頃はXML形式でデータの送受信を行うものが多かった覚えがあります。要因の一つとしてはRSSフィードがあります。RSSフィードはブログの文化とともに成長し、今では殆どのブログがRSS（またはAtom）フィード出力をサポートしています。そのRSSフィードがXML形式であり、多くのライブラリが既に作られていたこともあって、それを流用できる利点がありました。
しかしXML形式は可読性が悪い、タグが多く手続きが面倒、文字が多い分送受信コストが高いなどの理由によって次第にJSONフォーマットに置き換わるようになってきます。JSONはJavaScript Object Notationの略で軽量なデータ記述言語になります。JavaScriptとついている通り、JavaScriptから簡単に扱えるのが特徴です。また、現在では殆どのプログラミング言語においてJSONフォーマットを扱うライブラリがリリースされています。
JSONフォーマットでデータを送受信する利点として扱いやすさもありますが、Webブラウザ、つまりJavaScriptからWeb APIを扱いたいというニーズに応えられるというのがあります。当時のWebブラウザでは異なるドメインのサイトにアクセスする際にセキュリティ上の問題があったため、JSONPと呼ばれる回避方法が人気を集めました。ただしJSONPではGETメソッドしか扱えない、現在はCORSの設定を行って外部からも扱えるようにするケースが増えています。CORSはCross-origin resource sharingの略で、クロスドメインにおけるデータ授受の指定になります。
マッシュアップサービスの登場
Web APIが出始めるのに合わせて出てきたのがマッシュアップと呼ばれるサービスです。マッシュアップとは元々音楽用語で複数の音楽をミックスして別な音楽を作り出すものになります。つまりWeb API同士を組み合わせることで別な価値を生み出すというのがマッシュアップになります。
例えば地図サービスと不動産サービスのWeb APIを組み合わせたり、天気と音楽など一見すると関係がないようなサービスも組み合わせることで新しい価値を見いだすことができます。そうしたマッシュアップサービスは膨大なデータを手軽に扱うことができ、本体のサービス側では提供が難しい（ライバル同士のサービスを合わせるなど）場合もあり、注目を集めました。
マッシュアップサービスの例（旅行アシストサイト MyPlan マイプラン - 都道府県・お城・世界遺産の写真から旅行計画を作成
RESTfulの台頭
Rubyで作られたフレームワーク、Ruby on Railsが提唱したのがRESTfulでした。RESTとはWebなどで使われるソフトウェアアーキテクチャのことですが、そのRESTの原則に従うシステムをRESTfulと呼びます。例えばユーザ（user）について操作するWeb APIを考えた場合、
# メソッド # パス
POST /users # 新規作成
GET /users # ユーザ一覧の取得
GET /users/1 # ユーザID = 1のユーザ情報を取得
PUT /users/1 # ユーザID = 1のユーザ情報を更新
DELETE /users/1 # ユーザID = 1のユーザ情報を削除
といった形でHTTPメソッドとパスで何のオブジェクトに対する何の操作かが明確になります。さらに送受信にJSONを用いる場合は、
POST /users.json
GET /users.json
GET /users/1.json
PUT /users/1.json
DELETE /users/1.json
といった形になります。Ruby on Railsが標準でRESTfulに則って作られていたため、開発者にとってどの機能が呼ばれているかが分かりやすく、Web API利用者にとっても使いたい機能が使いやすいという利点もあり、現在数多くのWeb APIはRESTfulに提供されています。
Web APIがサービスを進化させる
TwitterがWeb APIのあり方を大きく変えたと言えます。それまで本体のWebサービスがある中で付随的にリリースされていたのがWeb APIでした。しかしTwitterの場合、公式サービスは機能があまり多くなく、かつWeb APIでほぼ全てのTwitterの機能が使えるようになっています。そのため開発者はTwitterのWeb APIを使い、数多くのクライアントソフトウェアや関連サービスを生み出していきました。これらはTwitterの成長を支える大きな力になったと言えるでしょう。
同様にFacebookのように自社で抱える巨大なユーザベースを外部に公開し、結果的にFacebookを成長させるというモデルがあります。この場合、Web APIにおける認証が大きな鍵になっていました。そこでFacebookはOAuthと呼ばれる仕組みを使い、ユーザ自身にどのデータを開発者に渡して良いかをコンロトールできる方法を採用しました。
アプリの世界
Web APIが爆発的に広がるきっかけになったのがスマートフォンアプリではないかと思います。スマートフォンアプリはそれ単体で使われるものは多くなく、何らかの形でインターネット上のサーバとデータの送受信を行っています。そうした時にサーバ側はWeb APIを用意し、アプリからはWeb APIを呼び出します。一般的に外部の開発者に向けて公開されているものがWeb APIと思われますが、こういったそのアプリ向けだけの専用かつ非公開なWeb APIはとても数多く存在します。
また、アプリビジネスに乗る形で作られている各種SDK（広告配信、mBaaS、アクセス解析系など）もWeb APIを使ってアプリとデータの送受信を行っています。これらはWeb APIというURLではなく、SDK（Software Development Kit）という形でラッピングして提供されています。そのため開発者はWeb APIを意識せずにその機能が使えるようになっています。
今後はどうなるのか
Web APIは新しいWebサービス、アプリを作る上で欠かせない存在になっています。また、これまではコンシューマがホビー用途で使うことが多かったのですが、多くの企業がサービス間連携を行う際にWeb APIを利用するようになっています。
つまりWeb APIは開発者の間においては当たり前の存在になってきたと言えるでしょう。それに伴い、ただWeb APIを公開したくらいでは開発者の目を引けなくなっています。そのため関連ライブラリやSDKの提供、分かりやすいドキュメント、デモなどを見せる必要があるでしょう。
そして何よりWeb API自体の魅力が問われるようになっています。そのWeb APIを使うことでどういったサービスが作れるのか、その未来を感じさせることが重要になっているのではないでしょうか。