インテグレーション

API とは

アプリケーション・プログラミング・インタフェース (API) は、アプリケーション・ソフトウェアを構築および統合するためのツール、定義、プロトコルで構成されています。製品やサービスが、他の製品やサービスの実装方法を知らなくてもそれらと通信できるようになります。API は、アプリケーション開発のシンプル化と、開発者の時間および企業コストの節約を可能にします。新しいツールや製品を設計する場合、あるいは既存のものを管理する場合、API を使用することで柔軟性がもたらされ、設計、管理、および使用方法がシンプルになり、イノベーションの機会が生まれます。

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

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

  • 顧客が API 経由でデータにアクセスできるようにすることで、在庫に関する情報を 1 カ所に集約することができます。
  • 取次業者は、API の動作が変わらない限り、顧客に影響を与えることなく内部システムを変更することができます。
  • API を公開するなら、取次業者、書籍販売者、または第三者向けにソフトを開発している開発者は、それを利用してユーザーが探している書籍を見つけるのに役立つアプリを開発できます。これは、売上高の増加や、他のビジネスチャンスにつながる可能性があります。

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

API のリリースポリシーには 3 つのアプローチがあります。

プライベート

API を社内使用に限定します。企業は API を最大限に制御できます。

パートナー

API を特定のビジネスパートナーと共有します。品質を損なうことなく追加の収益源を提供することができます。

パブリック

誰でも利用可能な API です。サードパーティは、あなたが開発した API と通信するアプリケーションを開発できるため、イノベーションが生まれる可能性を秘めています。

API によるイノベーション

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

  • 新しい収益チャネルを創出、または既存の収益チャネルを拡張
  • ブランドのリーチを拡大
  • 外部開発とコラボレーションを通じて、オープンなイノベーションや効率化を促進

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

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

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

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

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

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

API の歴史:超概略

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

リモート API

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

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


API 改良の道のり

API が今ではユビキタスな Web API に発展したので、それらの設計をいくらか容易にし、実装をより役立つものにするためにいくらかの努力が払われてきました。

少しの SOAP とたくさんの REST

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

もう 1 つの仕様は、Representational State Transfer (REST) です。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 よりも普及しています。

SOA とマイクロサービス・アーキテクチャ

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

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

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

API と Red Hat

Red Hat は、オープンソースやオープンスタンダードを通じて、オンプレミスでもクラウドでも利用可能な、軽量で包括的なモジュール式 API ソリューションを提供します。

プラットフォーム

さまざまな IT 資産を分散した柔軟な統合プラットフォームに統合します。Red Hat Fuse は、すべてを統合するために必要なインフラストラクチャとツールを提供します。

プラットフォーム

API の共有、セキュリティ保護、配布、制御、収益化を容易にするプラットフォームを使用して、社内外のユーザーを対象とした API を管理します。