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を使うことでどういったサービスが作れるのか、その未来を感じさせることが重要になっているのではないでしょうか。

NTTコミュニケーションズの緒方です。 開発者ブログでは、APIに関する技術情報や、API利用に関するベストプラクティス、お客様ビジネスにおけるユースケースなどを紹介していきます。 まず第１回は、NTTコミュンケーションズが提供するAPIゲートウェイのご紹介です！ APIゲートウェイとは？ NTTコミュニケーションズが提供するサービスのAPIを取りまとめたゲートウェイです。 NTTコミュニケーションズでは、サービスのお申し込みから運用保守に至るまでのビジネスプロセスに関する情報の閲覧・操作やサービスの設定変更などを、企業のお客さまが利用する各種システムからダイレクトにコントロール可能とするAPIを提供しています。 サービス毎のAPI接続形式/データ書式を統一して提供したり、API利用ログの一元管理を実現するためAPIゲートウェイを開発しました。 APIゲートウェイは、NTTコミュニケーションズが提供する法人企業向けサービス契約があれば無償で利用することができます。 何ができるの？特徴は？ 1. API認証の統一 NTTコミュニケーションズが提供するAPIの認証を統一化します。 APIのリソース要求単位で認可制御ができる権限管理機能も実装していく予定（今年夏頃）です。 2. 万全なAPIセキュリティ DDoSアタックやAPIに特化したセキュリティ対策（API Callのデータ部分の解析など）を各サービス横断で導入し、安全性を確保します。 3. APIログ管理 API利用ログを参照することができます。ログは無償で過去１年分参照可能です。 ログの参照はJSONベースで出力可能なため、市販/OSSログ解析ツールなどを利用してログを管理することができます。 システム監査などでAPIログ管理機能をご活用頂く事が可能です。 4. API変換 統一された接続形式(REST API)/データ形式(JSON/XML)に変換します。 NTTコミュニケーションズが提供する複数のサービス(API)を利用したシステムを開発する際のコストを削減することができます。 利用可能なAPIは？ 2015.6現在、APIゲートウェイを経由して利用可能なAPIは以下の通りです。 詳細はAPI Docsをご確認ください。 OAuth API Business Process API API Log API Cloudn Compute API Arcstar Universal One Mobile Global M2M API 利用シーンは？ 様々な利用シーンでAPIを活用することができます。一例として、自社のサービスオーダ管理システムとNTTコミュニケーションズのAPIを連携させて、人が介在しない正確なオーダ管理を実現することができます。 また、Cloudn Compute APIを利用して、仮想サーバの各種操作を自動化することもできます。例えば仮想サーバの起動や停止、複製といったAPI操作をスクリプト化しておき、特定のイベントが発生したときにスクリプトを自動実行するといった仕組みを実現させることが可能です。 サービスのメンテナンス状況などもAPIから取得することができるので、これらを上手く活用して運用オペレーションの改善も期待できますね。 今後の予定は？ ネットワーク・クラウド・ボイス・アプリケーションの分野にてAPIの提供拡充を目指します。同時にAPIゲートウェイの機能拡充もやっていく予定です。 加えて、SDK(ライブラリ)やAPIを活用したサンプルアプリなどAPI利用ツールを整備していきます。これら利用ツールはオープンソースとして順次公開していく予定です。 第一弾として、Business Process APIを活用したデモアプリをGitHubに公開していますのでご活用ください！ Business Process API活用 サンプルWebAppコードをGitHubに公開 NTTコミュニケーションズのAPIを試用したいんだけど？ まずはデベロッパーポータル（本サイトです）からAPIキーを入手してください！ APIキーがあれば、契約中サービスで公開されているAPIを全て無償で利用できます。 APIキーの入手方法は、 こちら をご確認ください。