ログイン / 登録 アカウント

統合

API とは

Application Programming Interface

API とは、アプリケーション・ソフトウェアを構築および統合するために使われるツール、定義、プロトコルです。API は、Application Programming Interface (アプリケーション・プログラミング・インタフェース) の略です。

API を使用することで、他の製品やサービスの実装方法を知らなくても、利用中の製品やサービスをそれらと通信させることができます。また、API を使用するとアプリケーション開発をシンプルに行えるようになり、時間とコストを節約できます。新たなツールや製品を設計する場合も、利用中のものを管理する場合にも、API を使用することでシンプルかつ柔軟な運用が可能となるだけでなく、イノベーションを起こすチャンスにもつながります。

API の仕組みは、文書による合意や契約に例えられることがあります。これはつまり、一方が特定の方法で構成されたリモート要求を送信し、他方のソフトウェアは指定された方法で応答する、というものです。

API を使うメリット

コラボレーション、スピード、競争力の強化

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

データの共有と収益化

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

各種業界の大手が API 活用で得た成功とその鍵について読む→

API 連携の図解:バックエンドシステム / API / API 管理システム / アプリ、IoT デバイス、モバイル機器

API によるメリットの具体例:出版取次の場合

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

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

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

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

API の公開ポリシー

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 に発展したので、それらの設計をいくらか容易にし、実装をより役立つものにするためにいくらかの努力が払われてきました。

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 よりも普及しています。

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

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

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

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

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

API 活用を支援する Red Hat ソリューション

Red Hat は、オープンソースやオープンスタンダードを通じて、オンプレミスでもクラウドでも利用可能な、軽量で包括的なモジュール式 API ソリューションを提供します。このソリューションは、既存の統合インフラストラクチャを変革して柔軟性を向上し、価値提供を迅速にするという、大きな役目を果たします。

ミドルウェア

Red Hat Integration

ハイブリッド・インフラストラクチャ全体でアプリケーションとデータを接続するための統合およびメッセージング・テクノロジーの包括的なツールで、インテグレーション開発を効率化します。Red Hat Integration は、アジャイルで分散型のコンテナ化された API 中心のソリューションです。

ミドルウェア

Red Hat Runtimes

クラウドネイティブ・アプリケーションの開発とメンテナンスに役立つ製品、ツール、コンポーネントを 1 つのセットとしてまとめて、アプリケーション開発と提供を迅速化します。Red Hat Runtimes は、マイクロサービスなど、高度に分散化されたクラウドアーキテクチャ用の軽量なランタイムとフレームワークを提供します。

ミドルウェア

Red Hat Process Automation

ビジネス上の意思決定とプロセスをインテリジェントに自動化するための製品セットで、変化するビジネスニーズにすばやく適応します。ビジネスポリシーと手順を実行し、ビジネス運用を自動化、そして異種環境でのビジネスアクティビティの結果を測定します。