API について理解する

アプリケーション・プログラミング・インタフェース (API) は、アプリケーション・ソフトウェアとサービスを統合するためのツール、定義、プロトコルで構成されています。これにより、毎回新しい接続インフラストラクチャを構築することなく、製品やサービスが他の製品やサービスと通信できるようになります。

API は、プライベート API (内部使用のみ)、パートナー API (特定の提携企業と共有して収益化)、パブリック API (API と連係するさまざまなアプリケーションをサードパーティが開発できるためイノベーションの促進が可能) に分けられます。API の共有には、以下のようなメリットがあります。

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

RESTful API および SOAP とは

Simple Object Access Protocol (SOAP) と Representational State Transfer (REST) はいずれも、API の設計を単純化し、実装における API の有効性を高めるものです。Web API が普及するなか、SOAP はメッセージフォーマットとリクエストを標準化する目的で開発されました。SOAP は、異なる環境や異なる言語で記述されたアプリケーション間の通信を容易にするプロトコル仕様です。一方、REST はアーキテクチャのスタイルです。REST は、規定のプロトコルより容易に準拠できる 6 つの指針に依存しています。そのため、RESTful API は SOAP よりも普及しています。

詳しくは続きをお読みください。

API の真価はインテグレーション (統合) です。つまり、すべてのテクノロジーがより機能的に通信し、連携できるように IT 組織全体でデータ、アプリケーション、デバイスをつなげることです。テクノロジー間でうまく連係できなければ、時間と資金を浪費することになります。API は、分散インテグレーションやコンテナと並んで、アジャイル・インテグレーションの重要な役割を果たします。

アジャイル・インテグレーションは、小さな IT フットプリントを重視した統合プラットフォームのアーキテクチャ・アプローチであり、スケーラビリティと可用性が高く、適切に定義および管理される再利用可能なエンドポイントを備えています。Red Hat では、相互接続されたシステムの未来の姿は、チーム間とそのテクノロジー間のコラボレーションに対応するに留まらず、そのようなコラボレーションを奨励するものであるべきだと考えています。テクノロジーが頻繁に形を変えていくなか、アジャイル・インテグレーションこそが、ビジネスの変革をサポートする最適な方法であると確信しています。

組織は、変化の激しい顧客からの要求に対応できるよう、API を管理する戦略を実施しています。HTTP ベースの API はマイクロサービス・アーキテクチャの中で同期したインタラクションを行うために推奨される手法になりました。このような API は、すべてのマイクロサービスをつなげる接着剤の役割を果たします。

このような API を管理すると、API を企業ポリシーに準拠させることができ、一部のサービスは他のサービスとは異なるセキュリティポリシーが必要となるため、適切なセキュリティレベルで統制できます。

貯金を布団の下に隠しておく人は、おそらくいないでしょう。ほとんどの人が信頼できる環境 (銀行) に預けて、支払いの承認と認証に別の方法を使用します。API セキュリティはこれに似ています。つまり、承認と認証のポリシーを有する信頼できる環境が必要です。

API セキュリティのベストプラクティスは、トークン、暗号化と署名、クォータとスロットリング、API ゲートウェイを使用することですが、優れた API セキュリティに最も重要なのは、優れた API 管理です。

API は、多くの人から次世代のビジネス開発と目されているものの要石です。API は Web プレゼンスの根幹を担うものであり、他のユーザーは API を使用してデータやリソースにアクセスし、公開済みあるいはプライベートのサイトやアプリケーションに統合できます。

理想的には、API 管理プランを実施するときまでに、収益化の目標に向けたフレームワークとなる健全なビジネスモデルも策定済みであることが望まれます。API の収益化とは、単に API で収益を創出することではありません。API が適切に稼働を続け、ユーザーが問題なく利用できる状態を保つ方法を考えることでもあります。

API は先進的な組織をデジタルでつなげる手段となり、運用や製品からパートナー戦略まで、あらゆるものに新しい機能を追加しています。今や、ほとんどの組織が API プログラムを導入すべきかどうかではなく、どのように導入すべきかを検討する段階に入っているといっても過言ではありません。

API プログラムの実装を準備しているなら、API プログラムの設計に備えて検討すべき 3 つの確認事項があります。

API ゲートウェイは、クライアントとバックエンドサービスのコレクションの間に位置する API 管理ツールです。

API ゲートウェイは、リバースプロキシとして機能します。すべてのアプリケーション・プログラミング・インタフェース (API) 呼び出しを受理して、それらを実行するために必要なさまざまなサービスを集約し、適切な結果を返します。

GraphQL は、API 向けのクエリ言語とサーバーサイドランタイムの両方を指します。クライアントがリクエストしたデータだけを提供することを優先します。GraphQL は、API の速度、柔軟性、開発者にとっての使いやすさを向上させるために設計されました。GraphQL は REST の代わりに、データを複数のデータソースから取得するリクエストを 1 つの API 呼び出しで構成できます。

Red Hat は、オープンソースやオープンスタンダードを通じて、オンプレミス、クラウド、ハイブリッドのいずれの環境でも利用可能な、軽量で包括的なモジュール式 API ソリューションを提供しています。API の実装と管理を行うための優れたソリューションがあれば、組織はビジネス目標に集中することができます。Red Hat の API ソリューションは、再利用性や IT のアジリティに加え、測定、監視、スケーリングを支援する管理インタフェースを重視した設計になっており、組織の成長に合わせて拡張することができます。

あらゆるオープンソース・プロジェクトと同様に、Red Hat はアップストリーム・コードベースにコード提供や機能改良の点で貢献し、技術の進歩に寄与してきました。コミュニティとのコラボレーションは、ただのコード開発にとどまりません。コラボレーションとは、自由に質問したり機能改良を提供したりできるということです。これこそが、The Open Source Way (オープンソースウェイ) であり、オープンな組織の強みです。Red Hat が 25 年以上にわたって信頼されるエンタープライズ・インフラストラクチャ・プロバイダーであり続けている理由が、ここにあります。