ITアーキテクチャに最適なAPIを選択するために

一部英語のままなので日本語化してみる

• ITアーキテクチャに最適なAPIを選択するために

アプリケーション・プログラミング・インタフェース（API）は、特定のアプリケーションやプラットフォーム、インフラストラクチャなどからデータを開放し、他のアプリケーションやシステム、デバイス、データベースへの接続を可能にします。その高い利便性から、APIには膨大な数のタイプが存在しています。実際に取り組んでいるプロジェクトに最適なAPIのタイプを的確に選ぶには、ユースケース、APIにアクセスするユーザ、接続させるシステムやデータベースといった複数の要素を考慮しなければなりません。効果的なAPIパフォーマンスとAPI管理には、アーキテクチャの構築および設計に最適となるAPIタイプを選ぶことが必須となります。

目的別のAPIタイプ

APIの指名買いはありません。ほとんどの場合、複数のシステムやDBを接続させた後のデータの使途や利用アイデア、搭載アプリケーション、新規ビジネス、ユースケースを明確にした後に、導入するAPIのタイプを決めていることと思います。

コアシステムの機能の社内公開から、顧客向けのモバイルアプリの展開まで、目的に応じて様々なAPIが採用されます。MuleSoftの『API主導の接続性アプローチ』では、目的に応じてAPIを3つのカテゴリーに分類しています。

• システムAPI：組織内のコアシステムからデータを開放します。システムAPIがデータを開放するコアシステムには、ERPや請求システム、顧客CRM、専用データベースなどがあります。
• プロセスAPI：単一システムまたはシステム全体でデータを連携かつ統合させ、データのサイロ化を解消します。プロセスAPIは、特定のビジネス目的を達成するためにデータを接続・連携・統合させることで、複数のシステムAPIを統制（オーケストレート）することができます。例えば、受注処理や配送モニタリング、360度顧客ビューの構築などを実現できます。
• エクスペリエンスAPI：モバイルアプリや代理店向けのポータルなどにデータを公開し、利用者が見たい情報を提示したり、やりたい業務をサポートします。エクスペリエンスAPIは、システムAPIによって開放されたデータとプロセスAPIによって確立されたプロセスに、ビジネス的価値を付加します。

API管理戦略

ユースケースが決まった次は、誰がAPIにアクセスするかを明確にします。ほとんどの場合、ユースケースと想定ユーザは密接に関係しています。たとえば営業担当とサービス担当のために顧客データを公開したい場合、想定エンドユーザは社内従業員になります。

以下に、APIの管理方法と想定ユーザに基づいて分類する、3つのAPIタイプを説明します。

外部API（エクスターナルAPIとオープンAPI）

外部 API は、組織外部のサードパーティ (開発者、パートナーなど) がアクセスできます。多くの場合、革新的なアプリケーションや統合を作成しようとしている世界中の開発者が、組織のデータやサービスにセルフサービスで簡単にアクセスできるようになります。

オープン API の例として、Google Maps API があります。これは、サードパーティ アプリケーション (ライドシェアやフード デリバリー アプリなど) 全体で使用され、位置の追跡やマッピングを可能にします。

内部API

内部 API はオープン API とは反対で、外部の消費者はアクセスできず、組織の内部開発者のみが利用できます。内部 API を使用すると、DevOps やマイクロサービス アーキテクチャの採用からレガシーの近代化やデジタル変革まで、企業全体の取り組みが可能になります。これらの API の使用と再利用により、組織の生産性、効率性、俊敏性を高めることができます。

再利用可能な内部 API の例としては、コール センター チームが顧客情報 API を作成し、顧客の名前、連絡先情報、アカウント情報などにアクセスできるようにした場合が挙げられます。その後、そのチームは顧客向けの Web アプリケーションやモバイル アプリケーションで同じ API を再利用できます。

パートナーAPI

内部APIと外部APIの中間に位置するのが「パートナーAPI」です。組織外部者が（排他的ではあるが）特別な権限をもってアクセスできるAPIです。通常、この特別なアクセス権限は、戦略的なビジネスパートナーシップを促進するため、特定のサードパーティに付与されます。

パートナーAPIのユースケースとしては保健所とその地域の病院といった、2つの組織が互いにデータを共有したい場合が挙げられます。パートナーAPIは、認証情報と権限の適切な組み合わせにより、各組織が必要なデータにアクセスできるようにセットアップされます。

APIアーキテクチャのスタイル

どのようなAPIアーキテクチャを採用するか？ということも、APIのタイプ選択のために重要な要素となります。特定の機能を必要とする場合、APIの目的や使途のサポートに最適なアーキテクチャやパターンを選択しなければなりません。この選択は、技術に精通したチームによって判断される傾向があります。

この判断を下す前に、自社のITインフラストラクチャを把握しておかなければなりません。すなわち、「システムがオンプレミスなのか？」「クラウドなのか？」「どのプラットフォームやDBを使用するのか？」「どのようなセキュリティプロトコルを実装すべきか？」「どういった機能が必要か？」など。 既存のレガシーシステムがこれから開発・実装するサービスや機能を限定するのではなく、ユーザが望んでいるサービスや機能が既存システムのアップデートやモダナイズを決定すべきなのです。これは『APIファースト』の設計思想に他なりません。

APIアーキテクチャには数多くの種類が存在しますが、以下に代表的なAPIアーキテクチャを紹介します。

• REST： REpresentational State Transfer（REST）は、基礎となるネットワーク・プロトコルに組み込まれたコマンドに依存することで、API利用者をAPI提供者から切り離すアーキテクチャスタイルです。クライアントは、組み込まれたリンクやフォームを使ってアクションを実行します（例：読み取り、更新、共有、承認など）。HTMLは、このスタイルの例として最もよく知られており、他にも多くのAPI専用のフォーマットがあります（HAL、CollectionJSON、Siren、他）。REST APIには、柔軟性や汎用性（JSONやXMLなどの一般的なデータ形式への対応）など、数多くのメリットが存在します。

• RPC：一般的にRemote Procedure Calls（RPC）とは、開発者が他のシステムに対し、特定のプログラムコードの実行をリクエストします。通常、開発者がRPCスタイルで他システムのプロシージャを呼び出すには、『手続き名称』を記述しなければなりません。RPCはプロトコルに依存しないため、多くのプロトコルでサポートされますが、同時にネイティブプロトコルの利点（例えばキャッシュ）も失われてしまいます。あるRPC APIから次に来るRPC APIへ『（非標準的な）手続き名称』を引き継ぐためには、APIのユーザと開発者の密な連携が必要です（少なくとも、その手続き名称を共有しなければなりません）。結果として、 RPC APIを主とするAPI エコシステムでは、開発者の負担を増大させることになります。RPCのアーキテクチャスタイルは、SOAP、GraphQL、gRPCなどが代表的です。

• イベントドリブン：イベントドリブンAPIは、API利用者のコールを待たずにレスポンスを返します。呼び方は、非同期API、ストリーミングAPI、プッシュAPI、リアルタイムAPIなど沢山あります。イベントの発生により、レスポンスが提供されることが最大の特徴です。これらサービスでは、イベントを公開しクライアントのサービス上の値が更新されるごとに、それら値の全てを受領（サブスクライブ）します。イベントドリブンAPIには、リアクティブ型、出版-購読型、イベント通知、CQRSなど、いくつかのバリエーションがあります。