API のメリットを知る

学習の目的

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

• 抽象化とは何かを定義する。
  
• API を使用するメリットを挙げる。
  
• HTTP の動詞とその使用法を説明する。
  

フィットネス機器を準備しながら、フィットネスクラブのオーナーは電気の仕様がなかったらこのプロセスはいったいどうなるんだろうと考え始めます。関係するのは機器だけではありません。壁の配線はもとより、それに接続されているその他の装置や発電の方法 (風力、電子力、火力、太陽光)、そして発電源の場所まで影響を受けます。幸いなことに、オーナーはこういうことを何も気にせずに、ただコンセントにプラグを差し込めば良いわけです。

API も同様の予測性と信頼性をもたらしてくれます。多くはコンテキストに沿った専用の接続性を提供します。API を使用した統合は、簡単に反復や拡張ができます。また、多くの場合に価値の相互交換が起こります。フィットネスクラブのオーナーは、トレッドミルに信頼できる電力を得ることができ、サービスプロバイダーはその消費量を測定して料金を請求できます。

API を使用するメリット

API は膨大な機会への扉を開放してくれます。ソフトウェア、お客様、シチズンインテグレーター、開発者、そのチームは API を使用することで次のようなメリットを得ることができます。

アウトソーシング

反復性という点では、対応する機器 (この場合はジムのマシン) は電気要件を簡単にサービスにアウトソーシングすることができ、これらのマシンはすべて同じ「動作する」という結果が得られるものと期待されます。同様に、API でも予測可能な標準インターフェースを通じて、主なデータや機能をアウトソーシングすることができます。共通でありながら特別な意味がある情報を取得するための方法をあれこれ考えるのではなく、優れたアプリケーション、サービス、カスタマーエクスペリエンスを実現することに注力できるのです。

Lyft が Google Maps への標準インターフェースを使用して、地図や位置情報をモバイルアプリにインポートする方法を考えてみましょう。タクシーやリムジンを利用するときには、地図がカスタマーエクスペリエンスに含まれることはありませんでした。一方、Lyft のような配車サービスは、地図をカスタマーエクスペリエンス改善のチャンスととらえました。

Google マップ の API があるため、Lyft はどうやって地図をアプリケーションにつなごうかと考える必要もありませんでした。優れたライドシェアエクスペリエンスを生み出すビジネスプロセスに専念できたわけです。

Integration Trailblazer を目指しているなら、API をこんな風に利用用して優れたカスタマーエクスペリエンスを作りたいという考えがごく自然に浮かぶと思います。このような考え方を組織の他の人に教えていくことが大切になります。

モビリティの向上

消費側のデバイスはソケット間を簡単に移動できます。たとえば、プラグがなく、対応するソケットや仕様がなければ、ジムのオーナーは壁に配線をして装置を接続しなければなりません。必要な工具を集め、壁を剥がして配線を繋ぎ合わせるという作業が必要になります。もちろん、壁から出ている配線についての知識も必要になります。

標準インターフェースがあれば、マシンの移動は簡単です。(ソフトウェアのアップグレードや、新しいサービスへの移行、データセンターフットプリントの拡大などと同じことです。) インターフェースのパターンが変わったとしても (実際、北米から英国に行くと変わります)、標準が明確に定義されているため、消費側のデバイスを簡単に適応させることができます。

抽象化

フィットネスクラブを例にすると、コンセントは基礎となるサービス、または電気の抽象化の 1 つの層です。さて、抽象化とは何でしょうか? 抽象化とは、別のシステムの動作の詳細を隠す 1 つの方法です。

120 ボルトの AC 電源がコンセントまで標準的な方法で供給されている限り、サービス提供者はソケットの裏側から電源供給元までの間は何を変更しても構いません。何を変更しても消費側デバイスからは見えません。

API は、提供されるデータや機能と、提供元でタスクを実行するために必要なロジックとの間の抽象化の層としての役割を果たします。言い換えれば、ソフトウェアは他のシステムへの接続方法が分かっていれば良く、他のシステムの動作の仕組みのことは知らなくて良いのです。

システム間のコミュニケーションに使用されるインターフェースは、アプリケーションがサービスを要求して、その応答でデータや機能 (地図の表示など) を受け取れるようにする、(電気の 120V AC 定格のような) 一連の合意された標準を表します。すべての API には、API の契約と呼ばれる、独自の合意された標準があります。この契約によって、意図したコンテキストで API を使用できるようになります。

開発者の生産性の向上

プログラマーがコードを書く場合、白紙の状態から書き始めることは滅多にありません。API は、機能を作り直そうとするのではなく、いつでもどこでも、既存のコードベースを土台として利用するように設計されています。既存のコードが再利用されるわけですから、アプリケーション間の差別化には限界があるとは言え、API への参照 (一般的には「API の呼び出し」と呼ばれる) によって、期待されるデータまたは機能をプログラムに提供できます。API は一般的なタスクを処理できるのはもちろん、それほど一般的ではないタスクも処理できるため、API を使用すれば、これまで何か月、あるいは何年もかかっていたアプリケーション開発が週単位にまで短縮できることがあります。

開発者がこの種の生産性を得られれば、ビジネスはかつてない俊敏性を実現できます。「API-Led Integration for Business Reinvention」 (ビジネス変革のための API 主導のインテグレーション) で学んだように、API のおかげで、新しい製品や、ビジネスのより効率的な進め方をかつての何分の一かの時間で実現できます。

HTTP プロトコルを使用したデータへのアクセス

アプリケーションを API に接続する方法を厳格に規定する規則や法規はありませんが、いくつかの標準が確立されてきています。たとえば、インターネットを通じてアプリケーションが API に接続する場合、API プロバイダーの大半は HTTP (ハイパーテキスト転送プロトコル)、別名 World Wide Web を経由した接続を提供しています。

携帯のアプリケーションで API を呼び出す場合も、Web ブラウザーを通じて現在のカロリー数を取得する場合も、フィットネスマシンのソフトウェアを通じてワークアウト情報を保存する場合も、「動詞」と呼ばれる特別な一連の HTTP コマンドが使用されています。

ほとんどの場合、サービスプロバイダーは、ソフトウェアが HTTP 動詞を使用して接続できるように、API エンドポイントと呼ばれる特殊な Web アドレスを用意しています。次に FitBit の例を示します。

GET https://api.fitbit.com/1/user/[user-id]/activities/date/[date].json

FitBit では、よくある「www」ではなく、「api」が使用されていますね。ここでは、開発者は GET コマンドを使用して、アプリケーションで表示するために必要なデータを返すことができます。このエンドポイントの場合、期待される応答には、最後のアクティビティ (ランニング) とユーザーが最近完了したフィットネスエクササイズが含まれます。

接続しているトレッドミルでこの API が使用されていれば、ランニングに役立つ情報がいろいろ表示されます。Fitbit API に GET リクエストを送信した後、受け取った応答を一例として見てみましょう。

API

もちろん、上記の応答はあまり直感的ではなく、トレッドミルのユーザーに表示されることはありません。これは、HTTP でよく使用される JSON (JavaScript Object Notation) と呼ばれる別の標準に従った形式です。非常に技術的に見えますが、MuleSoft Composer のような新種のシチズンインテグレーションツールがあり、プログラマー以外の人でもこれらの出力を簡単に操作することができます。これによりシチズンインテグレーターは API を使用する新しい方法について想像をめぐらし、そのインテグレーションを自分で構築することで想像力を基に行動することができます。プログラマーであれば、上記の応答を読み取って処理するためのコードを開発するかも知れませんが、事業部門マネージャーやトレッドミル設計者などのシチズンインテグレーターはクリックを使用します。

トレッドミルインターフェース

トレッドミルが応答を受信すると、ユーザーは総消費カロリー、最近のフィットネスチャレンジの追跡記録などを確認できます。

ここでは、トレッドミルのユーザーインターフェースの設計者の視点で考えてみましょう。何か別のユーザーインターフェースのアイデアが浮かんだりしていませんか? 応答の中の他のデータを利用してみるとか、そんなアイデアがあるかも知れませんね。ユーザーインターフェースを変更できるというこのような柔軟性は、API が提供する抽象化から得られるメリットの一例です。

実は、アプリケーションが同時に呼び出せる API は 1 つだけに制限されていません。1 つのアプリケーションで複数の API や API プロバイダーを呼び出すことができるのです。これらの複合アプリケーションは「マッシュアップ」と呼ばれることがあります。どんな材料を使ってもよいレシピのように、マッシュアップで何ができるかは、みなさんの想像力次第なのです。

ソフトウェア開発者とシチズンインテグレーター (シチズンインテグレーションツールが使える非プログラマーのユーザー) は、インターフェースを通じて非常に多数 (ProgrammableWeb.com の最近の計測によれば 2 万 3,000) の API にアクセスできるようになり、今や Web は Windows や Mac、Linux などのプログラマブルプラットフォームを凌ぐとは言わずとも、これらに匹敵するほどのプログラミングインターフェースへと変化を遂げています。いつでも使える大きなスパイスラックがあるようなものです。既製の材料から作られたマッシュアップとして組織のビジネスプロセスとカスタマーエクスペリエンスの見直しを早く始めれば、その分 API を使用したビジネス変革を早期に進めていくことができます。

リソース

• Trailblazer Community: MuleSoft Composer
  
• Trailhead: Lightning プラットフォーム API の基本