API とは

API はアプリケーション・プログラミング・インタフェース (Application Programming Interface) の略であり、アプリケーションをプログラミングするためのインターフェースという意味です。API はアプリケーション・ソフトウェアを構築し、統合するための一連の定義とプロトコルであり、ソフトウェア同士をつなぐ (連携させる) ことで、 アプリケーションの開発を容易にします。

これにより、他の製品やサービスの実装方法を知らなくても、利用中の製品やサービスをそれらと通信させることができます。また、アプリケーション開発が単純化されるので、時間とコストを節約できます。新しいツールや製品を設計する場合、あるいは既存のものを管理する場合、API を使用することで柔軟性がもたらされ、設計、管理、および使用方法がシンプルになり、イノベーションの機会が生まれます。

API は時に、両者間の合意を表す文書による契約に例えられることがあります。つまり、乙がある方法で構成されたリモート要求を送信し、甲のソフトウェアはその指定された方法で応答します。

API によって開発者が新しいアプリケーション・コンポーネントを既存のアーキテクチャに統合する方法が単純化されるので、ビジネスチームと IT チームのコラボレーションが容易になります。常に変化するデジタル市場に企業が対応するには、すばやく変化できる能力が必要となります。 新しい競合他社が新しいアプリケーションをもたらして業界全体を変革してしまうこともある状況で競争力を維持するには、革新的なサービスの迅速な開発とデプロイをサポートすることが重要です。クラウドネイティブ・アプリケーション開発は、開発速度を向上する歴然とした方法で、マイクロサービス・アプリケーション・アーキテクチャを API によって接続します。

API は、自社のインフラストラクチャをクラウドネイティブ・アプリケーション開発と接続するシンプルな方法ですが、データを顧客や他の外部ユーザーと共有する手段にもなります。パブリック API には、パートナーとつながる方法をシンプルにしながら拡張でき、データを収益化する可能性を秘めている (代表的な例は Google Maps API) という点で、独自のビジネス価値があります。

たとえば、書籍の取次業者を想像してみてください。取次業者の在庫を書店の店員が確認できるようにするには、クラウドアプリケーションを提供する方法があります。しかしこのようなアプリケーションは、開発コストが高く、プラットフォームの制限があり、長期間におよぶ開発と継続的なメンテナンスが必要になる場合があります。

取次業者はその代わりに、在庫状況を確認するための API を提供することもできます。このアプローチにはいくつかのメリットがあります。

• 顧客が API 経由でデータにアクセスできるようにすることで、在庫に関する情報を 1 カ所に集約することができます。

• 取次業者は、API の動作が変わらない限り、顧客に影響を与えることなく内部システムを変更することができます。

• API を公開するなら、取次業者、書籍販売者、または第三者向けにソフトを開発している開発者は、それを利用してユーザーが探している書籍を見つけるのに役立つアプリを開発できます。これは、売上高の増加や、他のビジネスチャンスにつながる可能性があります。

つまり、API を使用すると、セキュリティと制御を維持しながら、自分のリソースへのアクセスを開放することができるのです。アクセスを、どのように、誰に公開するかはあなた次第です。API セキュリティの中心は API 管理であり、それには API ゲートウェイの使用も含まれます。API に接続して、API が公開するデータや機能を使用するアプリケーションを作成するには、分散統合プラットフォームを使用します。このプラットフォームによって、レガシーシステムや IoT (モノのインターネット) を含め、あらゆるものが接続されます。

API をパートナーまたは一般に公開すると、以下のようなことが可能となります。

• 新しい収益チャネルを創出、または既存の収益チャネルを拡張

• ブランドのリーチを拡大

• 外部開発とコラボレーションを通じて、オープンなイノベーションや効率化を促進

いずれもすばらしいメリットです。しかし、API はどのようにこれらを実現するのでしょうか。

取次業者の例に戻りましょう。

同社のパートナーの 1 社が、書店の棚にある書籍を見つけるのに役立つアプリケーションを開発するとします。この改善された方法により、より多くの買い物客が書店 (つまり書籍の取次業者にとっての顧客) に来るようになり、既存の収益チャネルの拡大につながります。

あるいは、第三者がパブリック API を使用して、書店ではなく取次業者から直接書籍を購入できるようにするアプリケーションを開発することもあり得ます。これにより、取次業者に新しい収益チャネルが開かれます。

特定のパートナーとであれ、全世界とであれ、API を共有することはプラスの効果をもたらす可能性があります。API による連携により、自社のマーケティング活動を超えたブランド認知が実現します。パブリック API のように、テクノロジーを一般に公開することで、開発者はその API を中心にアプリケーションのエコシステムを構築することができます。あなたのテクノロジーを使用する人が増えれば、それだけ多くの人があなたとビジネスをする可能性も高まるのです。

テクノロジーを公開すると、新たな予期せぬ結果へとつながる場合もあります。これらの結果は、時には全産業を揺り動かします。取次業者の例を考えると、たとえば書籍レンタルサービスなどの新会社は、取次業者がビジネスを行う方法を根本的に変える可能性があります。パートナーおよびパブリック API は、社内の開発者よりもずっと規模の大きい外部コミュニティの創造的な取り組みを支援することができます。新しいアイデアはどこから来るかわかりません。企業は市場の変化を認識し、それに対応して行動する必要があります。そのような流れの中で、API が助けとなります。

API はコンピューティングの初期段階、パーソナルコンピュータが登場するよりずっと前に出現しました。当時の API は、オペレーティングシステム用のライブラリとして使用されていました。ほとんどの場合、API はそれが動作するシステムのローカルにありました。時にはメインフレーム間でメッセージを交換することもありました。ほぼ 30 年後、API はローカル環境から切り離されました。2000 年代初頭までに、API はデータのリモート・インテグレーションのための重要なテクノロジーとなっていました。

リモート API は、通信ネットワークを介して対話するように設計されています。リモートとは、API によって操作されるリソースが、要求を送るコンピュータの外にあることを意味します。最も広く使用されている通信ネットワークはインターネットであるため、ほとんどの API は Web 標準規格に基づいて設計されています。すべてのリモート API が Web API であるわけではありませんが、Web API がリモートであると考えるのは道理にかなっています。

Web API は通常、要求メッセージに HTTP を使用し、応答メッセージの構造の定義を提供します。これらの応答メッセージの形式は、通常 XML または JSON ファイルです。XML と JSON の両方とも他のアプリケーションが操作しやすい方法でデータを提示するため、好まれるフォーマットです。

Web API の普及に伴い、情報交換の標準化を支援するためのプロトコル仕様が開発されました。それが SOAP です。SOAP で設計された API は、メッセージ・フォーマットに XML を使用し、HTTP または SMTP を介して要求を受信します。SOAP を使用すると、異なる環境で動作しているアプリケーションや異なる言語で書かれたアプリケーションが情報を共有しやすくなります。

もう 1 つの仕様は、REST (Representational State Transfer) です。REST アーキテクチャの制約に準拠する Web API は、RESTful API と呼ばれます。根本的な点で REST はSOAP とは異なります。SOAP はプロトコルですが、REST はアーキテクチャのスタイルです。つまり、RESTful Web API の公式の標準は存在しません。Roy Fielding 氏の論文「Architectural Styles and the Design of Network-based Software Architectures (アーキテクチャ・スタイルとネットワーク・ベースのソフトウェア・アーキテクチャの設計)」で定義されているように、RESTful システムの 6 つの指針となる制約に準拠する限り、API は RESTful です。

• クライアントサーバー・アーキテクチャ： REST アーキテクチャは、クライアント、サーバー、およびリソースで構成され、HTTP を介して要求を処理します。

• ステートレス性： 要求と要求の間で、サーバーにクライアントのコンテンツは保存されません。代わりに、セッション状態に関する情報はクライアントが保持します。

• キャッシュ性： キャッシュは、クライアントとサーバー間のやりとりの一部を不要にします。

• 階層化されたシステム： クライアントとサーバー間のやりとりは、追加のレイヤーによって仲介できます。これらのレイヤーにより、ロードバランシング、共有キャッシュ、またはセキュリティなどの追加機能を提供できます。

• オンデマンドのコード (オプション)： サーバーは、実行可能コードを転送することによってクライアントの機能を拡張できます。

• 統一インタフェース： この制約は RESTful API の設計の中核であり、4 つの側面を含みます。

  • 要求によるリソース識別： リソースは要求で識別され、クライアントに返される表現とは別です。

  • 表現によるリソース操作： クライアントはリソースを表現するファイルを受け取ります。これらの表現には、修正や削除を可能にするのに十分な情報が含まれていることが必要です。

  • 自己記述的メッセージ： クライアントに返される各メッセージには、クライアントが情報をどのように処理すべきかを記述する十分な情報が含まれています。

  • アプリケーション状態のエンジンとしてのハイパーメディア： リソースにアクセスした後、REST クライアントは、現在利用可能な他のすべてのアクションをハイパーリンクを通じて見つけられる必要があります。

これらの制約は多く見えるかもしれませんが、規定のプロトコルよりもはるかに簡単です。このため、RESTful API は SOAP よりも普及しています。

先ごろ、REST API を定義する共通規格として OpenAPI 仕様が登場しました。OpenAPI を使用すると、開発者は言語に依存せずに REST API インタフェースを構築できるので、ユーザーが憶測で解釈する必要性が減少します。

もう 1 つの API 標準は、REST の代替となるクエリ言語およびサーバーサイドランタイムである GraphQL です。GraphQL は、クライアントがリクエストしたデータだけを提供することを優先します。GraphQL は REST の代わりに、データを複数のデータソースから取得するリクエストを 1 つの API 呼び出しで構成できます。

リモート API を最も使用する 2 つのアーキテクチャ・アプローチは、サービス指向アーキテクチャ (SOA) とマイクロサービス・アーキテクチャです。2 つのアプローチの中で古い方の SOA は、モノリシックなアプリケーションの改善策として始まりました。単一のモノリシック・アプリケーションはすべてを行うのに対し、SOA の一部の機能は別の複数のアプリケーションによって提供されます。そして、それらのアプリケーションはエンタープライズ・サービス・バス (ESB) のような統合パターンによって疎結合されています。

SOA はモノリシック・アーキテクチャよりもシンプルですが、コンポーネントの相互作用を明確に理解していないと、各種の変更が環境全体に連鎖的に波及してしまうリスクがあります。この複雑さゆえに、SOA が解決しようとしている問題のいくつかを逆に招いてしまうことがあります。

マイクロサービス・アーキテクチャは、特殊化したサービスを疎結合するという点で SOA のパターンとよく似ています。しかし、これまでのアーキテクチャをさらに細かく分解しています。マイクロサービス・アーキテクチャ内のサービスは、RESTful API などの共通メッセージング・フレームワークを使用します。サービス同士は、難しいデータ変換トランザクションや追加の統合レイヤーを使用せずに、RESTful API を使用して互いに通信します。RESTful API を使用すれば、新しい機能やアップデートを短時間で提供できるようになります。それぞれのサービスは独立しています。1 つのサービスの置き換え、拡張、削除がアーキテクチャ内の他のサービスに影響することはありません。このような軽量のアーキテクチャによって、分散型またはクラウドのリソースを最適化し、個々のサービスの動的なスケーラビリティを確保できます。

Webhook は HTTP ベースのコールバック機能で、2 つの API 間の軽量なイベント駆動型の通信を可能にします。Webhook はさまざまな Web アプリケーションで使用され、相互のアプリケーションから少量のデータを受信します。また、GitOps 環境で自動化ワークフローのトリガーにも使用することができます。

Webhook はリバース API やプッシュ API と呼ばれることもよくあります。通信の責任をサーバーではなくクライアントに任せるからです。クライアントが HTTP 要求を送信する、つまりサーバーが応答するまでデータを求めるのではなく、 データが利用できるようになったときにサーバーはクライアントに HTTP POST 要求を 1 回送信します。Webhook は、その呼び名とは異なり、API ではありませんが、両者は連携して機能します。Webhook を使用するには、アプリケーションには API が必要です。