Web API で Web を活用する

学習の目的

この単元を完了すると、次のことができるようになります。

• Web アプリケーションの人気が高まっている理由を 2 つ説明する。
  
• Web API の一般的な使用例を挙げる。
  
• API エコノミーと API の飛躍的な成長の理由を理解する
  

大変革をもたらすネットワーク化可能な API

API は同じローカルネットワーク上に限定されません。開発者とシチズンインテグレーターはリモートシステムやデバイスによって提供される API を使用することもできます。これには、複数の拠点やデータセンターを持つ企業のネットワークのような専用回線や、インターネットなどの公開ネットワークも含まれます。この広いネットワークへの鍵となるのが API エンドポイントです。

エンドポイントは、消費側のアプリケーションが接続するコンセントのようなものです。

コンセントに接続できる機器の数や種類を制限するものは、発明者の想像力と設備の容量だけです。同様に、API のエンドポイントによって抽象化されたデータを利用できるアプリケーションの数を制限するのは、開発者の想像力と API プロバイダーのインフラだけです。

代表例: Google が Google マップ用 API の提供を開始すると、多数のサードパーティ開発者がこの API を利用するユニークで革新的なアプリケーションを開発して、これらのアプリケーションに Google の地図機能を直接取り込めるようになりました。地図を提供する Yelp や Lyft、Tesla などのアプリケーションでは隅に Google の著作権情報が表示されています。

API がイノベーションのエンジンと呼ばれる理由はここにあります。特に、Integration Trailblazer は、多くの使用可能な API を、新しいビジネス成果やカスタマーエクスペリエンスを組み立てるための単なるサードパーティパーツとして見ています。

API エコノミー (経済圏)

呼び出しの量や、サービスをさまざまな層に分割する他の方法によっては、Google のようなプロバイダーがアプリケーション開発者に API の使用料を課すことがあります。これが API エコノミーという概念の発端となりました。

アプリケーション開発者は API を使用するためのコストと、いちから機能を開発するコストを天秤にかける必要があります。または、同様のサービスをもっと安価に利用できる他のプロバイダーを探すという手もあります。これは API エコノミーではよくあるケースです。たとえば、Google マップには Here.com などのよく知られた競合他社が数社あります。

デベロッパーの生産性向上と共通データへの渇望を満たそうとサービスプロバイダーがしのぎを削る中、API エコノミーは加速的に成長しています。API を通じて呼び出すことができるさまざまな機能のタイプ (クレジットカード処理や地図作成、ナビゲーション、翻訳など) ごとに、複数の API プロバイダーがアプリケーションデベロッパーやシチズンインテグレーターの注意を引こうと競い合っています。逆に、API ベースのサービスという形で多くの機能が提供されるようになると、API エコノミーは今度は主に既製の API で構成されるアプリケーションに向かって加速を始めています。最終的なソリューションが組み立てやすいほど、柔軟に他の API から新しい機能を利用しやすくなるため、全体的なビジネス機能で達成できるレベルが高くなります。

API の成長 - 過去と現在

ネットワーク対応 API は、食パン以来のすばらしい発明だと思っている人もいるかも知れません。そんなにすばらしいものをテクノロジー企業が何でもっと早く開発しなかったんだろうと思いませんか? いや、実は開発されていたのです。

Unix が登場した頃、RPC (リモートプロシージャーコール) という技術を通じて、ネットワーク経由で別のマシンから遠隔的にビジネスロジックを呼び出していたプログラマーは珍しくありませんでした。

ちょっと専門的な話になりますが、やがて RPC は、ネットワーク DDE (Dynamic Data Exchange) や CORBA (Common Object Request Broker Architecture)、電子データインターチェンジ (EDI) など、リモートデータや機能の別のリクエスト方式に取って替わられるようになり、最終的には XML-RPC (結局また RPC ですが) という形式が登場して、さらに XML と SOAP (Simple Object Access Protocol) に基づく Web サービスと呼ばれるものへと進化を遂げました。

データや機能へのリモートアクセスに対応する新しいテクノロジーが現れるたびに、ついにユートピアが実現したと業界は沸き立ちました。ところが、Web API のようなイマドキのテクノロジーが登場します。つまり、前述のように、GET や PUT、POST などの特殊な動詞を使って Web のプロトコル (HTTP) に織り込まれた機能に依存するテクノロジーです。そうです。お気に入りの Web サイトを訪問するのに毎日使用しているのと同じ Web プロトコルです。

(想像も含めた) インテグレーションの未来

これまでの歴史を根拠に考えると、システムを統合する方法はそろそろ変わる時期に来ていると思われます。いま人気の Web アプローチとは別に、比較的新しい 2 つの API に似たテクノロジーがあります。1 つは Facebook から生まれた GraphQL で、もう 1 つは Google の gRPC です。

現行の Web API と比較すると、どちらもそれぞれメリットがあります。たとえば、GraphQL は、ソーシャルグラフから発想を得て、友達や写真、勤め先などのさまざまなデータ項目が情報が相関する迷路をどのように構成しているかという概念に基づいています。(従来の API では同じ結果を得るために複数回のリクエストが必要であるのに対して) GraphQL では、データのグラフ全体に渡る情報を一度にリクエストすることができます。

他方、gRPC にも独自のメリットがあります。gRPC は、双方向のデータのストリーミングが可能な HTTP/2 (HTTP バージョン 2) を利用しています。HTTP/2 を使用して、gRPC は API を、データが利用可能になると瞬時に消費側アプリケーションにデータを送信するストリーミング API に変えることができます。従来の API ではアプリケーションが常に新しいデータがないかどうかチェックする必要がありますが、株式市場のティッカーのようなリアルタイムアプリケーションにとっては、こちらの方がはるかに効率的なデータの取得方法です。

同じアイデア、異なるテクノロジー

Web のプロトコル、GraphQL、gRPC、それ以外のこれから生まれる API アプローチのいずれでも、結局のところ、ネットワーク対応 API とは、他のアプリケーションがリモートからカスタマーエクスペリエンスのアウトソーシングしたパーツとして利用できるように、ビジネス機能をネットワーク対応サービスに変えるという概念です。アウトソーシング可能なパーツの在庫 (API エコノミー) が増えると、すべて社内開発で実現するのは難しいイノベーションやエクスペリエンスで競合を凌ぐ機会も増えていきます。

この機会には、別な方向でもメリットがあります。組織がネットワーク対応サービスとして API の形でそれ自体と外部開発者にもたらすビジネス競争力は何ですか? 文字どおり数百万ドルです。特に Integration Trailblazer を目指す人にとっては重要な答えです。