それぞれのニーズにマッチした API
学習の目的
この単元を完了すると、次のことができるようになります。
- API とは何かを定義して説明する。
- API の一般的な使用例を挙げる。
テクノロジーはもはや生活の一部となり、接続性は第 4 次産業革命の土台となりました。誰もが何らかの方法で繋がっています。
- 近所のレストランの評判を調べるには、携帯電話でYelp のレビューを確認し、
- 航空券やホテルを探すには旅行予約サイトを利用します。
- Alexa 対応の AmazonBasics の電子レンジからは直接、レンジ対応ポップコーンを注文できるなど、家電を通じたオンライン注文までが可能になっています。
いったいどういう仕組みになっているのだろう、と思ったことはありませんか?
ほとんどのコンピューターソフトウェアは長年に渡って「人間」というユーザーのみを対象に作成・提供されてきました。そのソフトウェアの下でどのような連鎖反応が起ころうとも、連鎖の末端にいるのは、常に「人」であるユーザーでした。ゆえに、ユーザーがデータにアクセスできる唯一の手段はユーザーインターフェース (UI) でした。
ただし、そのデータに別のソフトウェアを使用して同じように簡単にアクセスできるとしたらどうでしょう? たとえば、スマートウォッチがあなたの歩数を Web のパフォーマンスグラフサービスや、フィットネス改善の支援を依頼している医師が使用している電子健康カルテ (EHR) システムと共有する場合はどうでしょう? この場合、UI に関する配慮は異なってきます。ソフトウェアには目や感情や直観などありませんから、派手なグラフィカルユーザーインターフェースなどは不要になります。ただし、UI が人間用に作成されているのと同様に、ソフトウェアが他のソフトウェアからデータや機能を簡単に取得できるようにするインターフェースが必要になります。
そこで登場するのがアプリケーションプログラミングインターフェース (API) です。ある目的専用のコンテキスト (フィットネスデータの視覚化など) 内でアプリケーションやデータ、デバイスがデータや機能を共有するとき、そのコンテキストで発生する接続をバックグラウンドで担当するのが API です。
API とは?
API は、人間ではなくソフトウェア向けに設計されていること以外はユーザーインターフェースと同じです。API がアプリケーション同士の対話を可能にするテクノロジーとして紹介されることが多いのはこのためです。
クライアントが特定の情報または機能を別のシステムに送り、そのシステムが返信としてデータまたは機能を返します。データを送受信するには、双方で理解できる特定の形式でのやり取りが想定されます。多くの場合、その形式は使用されるコンテキストによって大きく異なります。詳しく見てみましょう。
フィットネスクラブのオーナーが新規オープンするジムに新しいマシンを接続したいと考えています。居住地は北米ですから、北米の家庭用プラグが必要です。また、コンセントの電圧は 120 V です。 この既知の条件によって壁のコンセントに接続するマシンの仕様が決まります。
API も同じです。
API: ソフトウェア間の電流
そもそも壁のコンセントが API にどう関係しているのでしょうか?
次のように考えてみてください:
- 壁から供給される電気は「サービス」です。いつでも停止したり、開始したりできます。
- 壁のコンセントに接続されたトレッドミルの動力源は電気です。
- トレッドミルには独自の電源供給元はないため、風力発電や太陽光発電などのサービスプロバイダーから必要な電力をアウトソーシングします。
コンセントは国によって異なりますが、差込み口の形には一定の標準パターンがあり、トレッドミルなどの機器に付いている電気プラグはこの標準パターンに合うように設計されています。
サービスを使用するマシンの要件は、これらの仕様によってに基本的に決まるわけです。プラグと電源はサービスの標準パターンと仕様 (120 ボルトなど) に対応しています。これは API も同じです。
電気コンセントに定格があるように、API にも他のソフトウェアとデータや機能を簡単にやり取りできるようにするための標準的なパターンがあります。データの送受信をするには、どのソフトウェアもこの仕様に従ってリクエストを送る必要があります。API によって、既存のプロセス (カスタマーエクスペリエンスなど) が新しいデータや機能につながるようになるのです。