API の利点を知る

学習の目的

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

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

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

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

API を使用するメリット

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

アウトソーシング

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

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

Google Maps の 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 動詞
説明
POST
要求されたデータをサーバに送信する
GET
要求されたデータをサーバから取得する
PUT
リクエストで送信された新しいデータで既存のデータを更新して置換する
DELETE
要求されたデータをサーバから削除する

ほとんどの場合、サービスプロバイダは、ソフトウェアが 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

アクティビティ ID や消費カロリー数、距離、歩数など、アクティビティとフィットネスエクササイズについて返される API データはマシンで簡単に解釈できるようにコード化されている。

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

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

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

トレッドミル UI では、FitBit API から受信したデータを使用してユーザの現在の状況を更新します。

次に、トレッドミルのユーザインターフェースの設計者の視点で考えてください。別のユーザインターフェースについて何かアイデアがありますか? 応答の他のデータを利用するアイデアをお持ちかもしれません。ユーザインターフェースに変更を加えるこのような柔軟性は、API が提供する抽象化から得られる利点の一例です。

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

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

リソース