アプリ、Webサービスと数多くのインターネットを使ったサービスが登場するのに比例してWeb APIも次々と作られています。Web APIのマーケットが拡がっていくことで認知が高まり、さらにWeb APIが開発されていくという好循環が生まれています。 その一方で乱立することによって、Web APIの品質が問題になってきます。Web APIではWebブラウザを使ったアクセスとは異なり、基本的にプログラムからのアクセスを考えなければなりません。そのため不用意なセキュリティホールがあったりすると、あっという間に大きな問題（データの消失であったり、乗っ取りであったり）が発生する可能性を秘めています。 そこで私たちはWeb APIの設計に際して標準規則を策定しています。その規則に沿ってWeb APIの開発を進めることで、可用性はもちろん堅牢性や安全性を意識した情報の提供ができるようになります。これまでのインタフェース、データフォーマットに続き、今回は バージョン管理、同期・非同期 について規則の一部を紹介します。 バージョン管理について Web APIのバージョン管理は常に話題にあがってきます。対応方法としては以下のパターンが考えられます。 URIのパスにバージョン番号を含める URIのパラメータにバージョン番号を含める 新しいWeb APIを作る 3.の新しいWeb APIを作る方法は機能の乱雑化を生みますし、メンテナンスコストを著しく悪化させるためお勧めできません。2.のパラメータに含める（/api?version=2など）はキャッシュの兼ね合いやロジックの複雑化につながる可能性があります。 そこで私たちはURIのパスにバージョン番号を含める方法を基準としています。つまり次のような形です。 https://example.com/v1/api v1がバージョン番号にあたります。こうすることでWeb APIの実装が大幅に変更された場合においても下位互換性を維持することができます。 同期・非同期の分け方について Web APIの場合、クライアントからネットワークを使ってアクセスしてきますので、あまり長時間のネットワーク接続が求められるものはタイムアウトしてしまう可能性があります。そのため最長でも30秒程度までを同期処理、それ以外は非同期処理として実装するのが良いでしょう。 エンタープライズレベルでのWeb API実装においてはトランザクション処理が求められることが多々あります。しかしHTTPを使ったネットワークとトランザクションは相性が良くありませんので、トランザクションを用いた処理の場合は非同期処理を用いるのが良いでしょう。 Web APIは一度作ったら終わりではなく、随時更新、変更されていくものです。この点においては通常のWebサービス、Webシステムと同様と考えられます。ただしWebサービスなどはUIを変えても利用者が使い方を習得してくれる一方、Web APIはリリース後は自動運転されることが多いので旧来の接続クライアントに常に気を配っておく必要がある点を注意してください。 ぜひ皆さんのWeb API設計において参考にしてください。

アプリ、Webサービスと数多くのインターネットを使ったサービスが登場するのに比例してWeb APIも次々と作られています。Web APIのマーケットが拡がっていくことで認知が高まり、さらにWeb APIが開発されていくという好循環が生まれています。 その一方で乱立することによって、Web APIの品質が問題になってきます。Web APIではWebブラウザを使ったアクセスとは異なり、基本的にプログラムからのアクセスを考えなければなりません。そのため不用意なセキュリティホールがあったりすると、あっという間に大きな問題（データの消失であったり、乗っ取りであったり）が発生する可能性を秘めています。 そこで私たちはWeb APIの設計に際して標準規則を策定しています。その規則に沿ってWeb APIの開発を進めることで、可用性はもちろん堅牢性や安全性を意識した情報の提供ができるようになります。前回のインタフェースに続き、今回は データフォーマット について規則の一部を紹介します。 データフォーマットはXMLまたはJSON 現在、Web APIで送受信されるフォーマットはXMLまたはJSONがデファクトスタンダードになっています。特に一般開発者向けに公開されるものはWebブラウザからも扱いやすいJSONが増えています。Webサービスをはじめ、エンタープライズ間でやり取りされるデータについてはXMLを使うことも多いです。 データのやり取りに際して旧来の手法であるCSVについては現在は非推奨とすべきです。項目の順番や長さによるデータ定義や改行やエスケープすべき文字が入った時の処理など、扱いの柔軟性が問題になります。 Web APIにおけるフォーマットの指定 Web APIが返す出力についてはリクエスト時にフォーマットが指定できるようになっているべきです。例えばURIで指定する場合は次のようになるでしょう。 http://example.com/〜.json # JSONリクエストの場合 または format パラメータに jsonまたはxmlなどと文字で指定する場合もあります。formatパラメータの場合、jsonp（JSON with padding）を指定することも考えられます。URL指定の場合はcallbackパラメータのあるなしでJSON/JSONPと出力を変えることが多いように見えます。 http://example.com/〜?format=json いずれの場合においても利用者が使いたいと思うフォーマットを動的に指定できるのが望ましいと考えています。 スキーマの提供 XML、JSONのいずれにおいても実装とAPI仕様の乖離を避けるためにスキーマを提供すべきです。XML Schemaは昔からよく知られていますし、JSONにおいても JSON Schema が定義されています。 パラメータ命名規則について パラメータ名は分かりやすいものをつけるのは当然ですが、大文字小文字についても注意が必要です。私たちはLCC（Lower Camel Case）を推奨しています。例えばユーザ名であればuserNameといった形で先頭を小文字に、その後の単語は頭を大文字にしています。その他の手法としては_（アンダースコア）を使う場合もあるかと思います。 文字エンコード 文字エンコードはUTF-8であるべきです。日本語をはじめ、複数バイト文字圏ではエンコーディングが最大の問題、かつ不具合の原因になりますので、UTF-8を使っておくのが安全であり、基本になるでしょう。 Web APIは人ではなくシステムを対象にして開発されています。そのため内部の実装がブラックボックスになり、Web APIおよびそのドキュメントがそのまま仕様として外部に公開されることになります。適切なWeb API設計を行うことがシステムの可用性、柔軟性、堅牢性につながることでしょう。 ぜひ皆さんのWeb API設計において参考にしてください。

アプリ、Webサービスと数多くのインターネットを使ったサービスが登場するのに比例してWeb APIも次々と作られています。Web APIのマーケットが拡がっていくことで認知が高まり、さらにWeb APIが開発されていくという好循環が生まれています。 その一方で乱立することによって、Web APIの品質が問題になってきます。Web APIではWebブラウザを使ったアクセスとは異なり、基本的にプログラムからのアクセスを考えなければなりません。そのため不用意なセキュリティホールがあったりすると、あっという間に大きな問題（データの消失であったり、乗っ取りであったり）が発生する可能性を秘めています。 そこで私たちはWeb APIの設計に際して標準規則を策定しています。その規則に沿ってWeb APIの開発を進めることで、可用性はもちろん堅牢性や安全性を意識した情報の提供ができるようになります。今回はその項目の一つである インタフェース について一部を紹介します。 REST APIであること 昨今のWeb APIの流れはREST APIにあります。つまりURLでデータ（リソース）を特定し、HTTPメソッド（GET/POST/PUT/DELETE）によってそのデータに対して行う操作を特定します。技術的に言うと、 HTTPメソッド 操作 GET READ POST CREATE PUT UPDATE DELETE DELETE に対応させるということです。詳しくは REST - Wikipedia をご覧ください。 プロトコル これから作られるWeb APIについてはHTTP 1.1になっているべきでしょう。HTTP 1.1についてはKeep-AliveとHOSTヘッダの特徴が挙げられますが、一般的なHTTPサーバであるApacheやnginxなどを利用している限りは特に意識することはないかと思います。Web APIを提供する上ではあえて独自のプロトコルを定義するようなことは避け、標準技術に沿って進めるのが良いでしょう。 Content-Type Web APIはデータを返却する際に適切なContent-Typeを設定しておく必要があります。今のトレンドとしては、XMLとJSONがあるかと思います。 XML XMLで使われるContent-Typeは以下の5つがあります。これは RFC 3023 で定義されています。 text/xml application/xml text/xml-external-parsed-entity application/xml-external-parsed-entity application/xml-dtd Web APIとして用いる上では application/xml がお勧めです。 JSON JSONで使われるContent-Typeは application/json のみ定義されています。これは RFC 4627 に記載されています。なのでJSONデータを返却する際には application/json を Content-Type として指定しましょう。 適切なWeb APIを設計すると、リリース後の更新において設計が破綻することがなかったり、拡張性も担保されるようになります。もちろん、設計が統一されることで不用意なセキュリティホールが出るのを防ぐこともできるでしょう。 エンタープライズにおけるWeb API開発および利用や評価において参考にしてください。

Web APIは自動化を担う仕組みになりますので常に一定のパフォーマンスが求められます。単純にアクセスしてレスポンスを返せばいいだけでなく、パラメータに対してロジックを実行した上で素早くレスポンスを返す必要があります。 今回はそうしたWeb APIのパフォーマンスをテストするロードテストに使える外部サービスを紹介します。 On Demand Load Testing for Developers & Testers | Load Impact 専用のツールを使って操作を記録し、その操作スクリプトに従ってロードテストを行います。スクリプトを修正し、異なるアクセス方法に変更することもできます。さらに異なるロケーションからのテスト（例えばイタリアなど）が行えたり、モバイル回線を使ったテストにも対応しています。 Application Load Testing Tools for API Endpoints with loader.io 無料で使えるのが大きなポイントのロードテストサービスです。APIも用意されていますので、Web API開発と組み合わせた運用も考えられるでしょう。 Performance and Load Testing from the Cloud - Blitz by Spirent 同時に20万の仮想ユーザおよび8つの異なるロケーションからのアクセスをサポートしています。Google ChromeとFirefox向けに機能拡張が提供されており、それを使うことでテストが容易に作れるようになります。自動化のためにはRuby向けのライブラリやAtlassian製のCIサーバと連携ができるようです。 Test Automation for DevOps パフォーマンステスト、CI連携のテスト、そしてモバイルパフォーマンステストが大きな特徴となっています。Apache JMeterと100%の互換性があります。テストについてはSeleniumを使っています。 API Performance Monitoring · Runscope テストは世界中の各地域から実行でき、Slackをはじめとして各チャットサービスに結果を投稿できるようになっています。監視サービスを含んでおり、問題が発生した時にすぐに気づける仕組みも提供されています。 Cloud Testing Platform | Cloud Load Testing for APIs and Websites, API & Website Monitoring and Website Speed Testing Tool for APIs, Websites and Mobile Applications Web APIのロードテストはもちろん、通常のWebサイトのモニタリングやスピードテストも行えるようになっています。 Apica | Advanced Load Testing Solutions. Flexible Load Testing Service Plans エンタープライズ向けにサービス提供されており、ハイボリューム（200万仮想ユーザ以上）でのロードテストが可能です。APIも提供されていますのでCIとの連携も行えます。 LoadUI - The Home of Load Testing | API Load Testing Tool LoadUIはSaaSではなくダウンロード型のソフトウェアになります。サーバの監視機能もあり、SaaSでは導入がしづらい企業においては良い選択肢になるのではないでしょうか。 ロードテストは負荷テストに比べてより実践的なデータを送受信するテストと言えるでしょう。そのためテスト設計が大変ではありますが、一度組んでしまえば後は自動化した上で開発する度にテストを自動実行できるようになります。 その上でデータが蓄積されて徐々に性能が劣化していくのをいち早くつかんだり、特に重たい処理を知ることで改善につなげることもできるでしょう。ぜひ使ってみてください。

Web APIというとWebサービス企業が外部の開発者に対してリリースし、マッシュアップを作ってもらうという印象があるかと思います。しかし、ここ数年はビジネスレベルにおいて企業間サービス連携としてWeb APIが利用されるようになってきています。 そこでエンタープライズレベルにおいてWeb APIをどのように使っていくべきか、または懸念点などを紹介したいと思います。 自動化 まず企業システムにおいて大事なのが自動化です。省力化し、対人コストを減らすことができます。特に電話やメールなどで問い合わせをし、それに対してオペレータが自社システムを検索した上でその返事をする程度であれば、そもそもWeb APIとして公開してしまうことができるでしょう。 その際に問題になるのはセキュリティではないかと思います。Web APIは一般的に各機能が独立して存在しており、それぞれの機能ごとに認証を行わなければなりません。そうなるとID、パスワードを記録しておく必要があるため、セキュリティ上のリスクになります。 そこでWeb API上でのみ使えるトークンを発行してパスワード代わりにしたり、OAuth2のような技術を使うのが一般的となっています。 企業間連携 お互いのサービスを連携させることでシナジーが生まれる場合、Web APIを用いた連携が行われます。よくあるのは旅行会社と航空会社のシステムであったり、最近では飲食店の予約システムとオンライン台帳システムが連携していたりします。お互いが足りていない機能を補完し合うことでサービスの利便性を高めるのに成功しています。 この場合、認証を介さない連携が行われることも多く、そのために接続できるIPアドレスを制限するのが一般的と思われます。また、完全に自動化した上で運用されるため、十分な相互接続テストが必要になります。 この利点としてはそれぞれの会社がWeb APIを作ってしまえば、同じ手法で他の企業とも連携できるようになるということでしょう。そのため、なるべく個別の企業向けに特化するのではなく、汎用的なWeb APIを作る必要があります。 従来は全銀協標準プロトコルやCAFISのような専用プロトコル、システムを定義していましたが、最近ではWeb APIを使ってインターネットを介してデータの送受信を行うのが一般的です。この場合、特にデファクトになるものがないケースはそれぞれドキュメントを用意した上で開発を行います。 クラウドサーバ ここ数年で注目の集まっているクラウドサーバにおいてもWeb APIが使われています。Web APIを通じてサーバをクラウド上に立ち上げる、または逆に消すといった操作が行われています。一時的にマシンパワーが必要になったタイミングで10数台（またはもっと）のサーバを立ち上げて処理を実行し、終わったら落とすと言った操作を行うことで膨大なマシンパワーを数百円程度で利用できるようになります。 また、サーバへのアクセスが増大した時に自動的に台数を増やして処理を並列化したり、必要がなくなったら落とすと言った具合にオートスケーリングさせるための仕組みや手法も広まっています。運用を自動化することはシステムの安定化において欠かせない要素になっています。そして、それを支える技術にWeb APIが使われています。 基幹システムとの接続 社内においてもWeb APIを使うことで業務を格段に早く、かつ確実なものにできます。外部のサービスにおいてはWeb APIを提供することが増えており、そうしたサービスからデータを引き出すことができれば基幹システムと接続して業務を自動化できます。 帳票や物流、倉庫業務など多くの場面において自動化が進められています。手作業でレポートやCSVをダウンロードしたり、転記したりするような手間はWeb APIを使うことで大幅に減らせるでしょう。 ジャストインタイム Web APIを使った場合の利点として、チェックを自動化できるということが挙げられます。問題が起きたり、状態が変わった時にチェックするといったこともWeb APIであれば簡単に自動化ができます。コンピュータは予め指定した処理を繰り返すのは得意であるため、そういった作業こそ自動化すべきでしょう。 そして閾値を越えたり、ステータスが変わったタイミングで担当者にメールなど、何らかのアラートを出すことができます。問題が起きた時に素早く対応できる体制はWeb APIを利用することで容易に実現できるでしょう。 データハブ Web APIを用意することで業務上、様々なところに散在するデータを一元管理することができます。例えばグループウェア標準のUIでは入力がしづらいケースもWeb APIがあれば専用のUIを作成し、運用が簡単になります。その結果、これまでは別途管理していたデータがグループウェアの中に一元管理されるようになります。 データが様々な場所にあるとそれだけ見る場所が増え、その結果として見逃すケースが増えてしまいます。Web APIを使うことでデータが集約されるとそれだけ運用コストが軽減されるでしょう。最近では Slack （Webチャットツール）が多くのサービスと連携し、メッセージハブとしての役割を担っています。 Web APIは単純に公開すれば良いというものではなく、その企業にとって戦略性を持ち合わせたものでなければなりません。特にエンタープライズレベルにおいては実際の業務上で利用されることを念頭においた設計、送受信されるフォーマットなどを考えなければならないでしょう。

Web APIのフォーマットとしてJSONの採用が増えています。JSONは軽量な記述言語で手軽に扱える反面、そのデータ内容に対する保証がしづらいのが問題視されています。そこで注目を集めているのがJSONの構造を定義するJSON Schemaです。JSONデータに対して型やメタ情報を付与することでフォーマットに対するルールを追加します。 JSON Schemaは現在仕様として策定が進められています。詳細は JSON Schema and Hyper-Schema にて確認することができます。 今回はJSON Schemaを導入することでどのような可能性が見えてくるのか考えてみたいと思います。 1. バリデーション まず最初に思いつくのはバリデーションです。これはクライアント、サーバ両方について行えます。データをポストする前に検証したり、受け取ったデータについてバリデーションを自動的に行えるようになります。 検証結果がエラーであれば、それをそのまま返せば良いでしょう。検証後の利用についてはデータ構造や型が保証されるので安心してコードを組めるようになります。 2. データを扱うライブラリの生成 こちらはWebサービスでよくあったスキーマ（WSDLなど）からコードを自動生成するのに似ています。Javaや.NETであればスケルトンコードを生成する形に、RubyやPHP、Pythonなどのスクリプト言語であればメソッドを自動生成する形になるでしょう。 JSONはパースした後、ハッシュや連想配列で扱うことが多いですが、予めコードを生成することでより扱いやすいデータとして使えるようになります。 3. ドキュメント生成 さらにJSON Schemaではデータ構造やURLに対する記述やパラメータの説明も行いますのでAPIドキュメントを生成するのにも使えます。実際のコードとは分離しますので整合性を保つ必要はありますが、後述するテストする仕組みと組み合わせることで最新の状態に保つことができるでしょう。 APIドキュメントを参照する開発者は多いので、このようなアウトプットがあることでJSON Schemaを適切にメンテナンスしていこうというモチベーションにもつながるはずです。 4. ダミーサーバ Web APIを扱うライブラリのテスト用サーバのベースとしてJSON Schemaが利用できます。サーバ内のロジック部分について保証できるわけではありませんが、ダミーサーバがあることでローカルでの開発やテスト環境下での実行が容易になります。 ただしダミーサーバでは入力値の必須や型などのチェックはできても、トークンの妥当性といったようなロジックのチェックはできません。あくまでも開発時の補助ツールとして使うのが良いでしょう。 5. テストの自動化 そしてWeb API自体のテストを行う際にもJSON Schemaが使えます。予め定義した値をポストして、予定されている結果が得られるかどうかを検証できます。Web APIの拡張を行っていて、例えば新しい必須項目を追加したためにこれまでWeb APIを使っていたシステムが突然動かなくなることがあります。そうした点においてもJSON Schemaをバージョン管理し、全てのバージョンで動き続けているかをチェックできるのは重要です。 Web APIを使ったソフトウェアは完成後、自動運転のフェーズになることが多々あります。そうした時でも結果を担保するためにJSON Schemaが利用できるでしょう。 6. 開発時のエラーチェック IDEなどであればJSON Schemaを取り込むことで予め警告を表示できるようになるでしょう。JSONの構造はテキストのままでは可読性が低く、読み違えることが多々あります。そうしたミスを防ぐのに使えるはずです。 JSON Schemaは幾つかのメリットがありますが、元々がWSDLなどの複雑さや面倒さから逃れるために生まれたこともあってなかなか普及していません。しかし今後エンタープライズレベルでWeb APIが使われていく中では重要な要素になってくるはずです。 単にやるべきだからやる、ではなくJSON Schemaを使って開発生産性を高めたり、ドキュメントを自動生成するなど負担を軽減することができれば、もっと使われていくのではないでしょうか。

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キーの入手方法は、 こちら をご確認ください。