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」です。多くの場合は、革新的なアプリケーションやインテグレーションを作成しようとする世界中の開発者が、組織のデータやサービスにセルフサービスで簡単にアクセスできるようにします。
Google Maps APIが「オープンAPI」の代表例となります。多くの方が利用した経験があると思いますが、このAPIを使用することで、ライドシェアや宅配アプリなどのサードパーティアプリ上にて、マップ検索や現在地の追跡が可能になります。
内部API
内部APIは、オープンAPIとは反対に、外部の利用者はアクセスできず、組織の社内開発者のみが利用できます。内部APIによって企業は、DevOpsやマイクロサービス・アーキテクチャの採用、レガシー・モダナイゼーションやDXの実現まで、幅広いITイニシアティブを実現化できます。これらのAPIの使用と再利用によって、組織の生産性、効率、俊敏性を向上させることができます。再利用可能な内部APIの例としては、コールセンターチームが、コールセンターアプリケーション内で使用する顧客情報のAPIを作成し、顧客の名前、連絡先情報、アカウント情報などにアクセスできるようにするなどです。チームはその後、この同じAPIを顧客向けWebアプリケーションやモバイルアプリケーションで再利用することができます。
パートナー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など、いくつかのバリエーションがあります。
私たちの周りには、APIパターンに適したイベントが数多くあります。以下は、そのごく一部となります。
- Twitterアカウントでツイートをポストする
- 遠隔の温度計の温度が変わる
- 遊歩道のセンサーの上を自動車（歩行者以外の物体）が通り過ぎる
- 防犯カメラが視野内の動きを検知する
- 心電計が不整脈を検出する
- 非常口のドアが開く
- 感知器が煙を感知する
組織に効果をもたらすAPIの設計と管理の実現のためには、多くのことを検討しなければなりません。ここに記した内容は、APIの設計、デプロイおよび管理のプラン段階に考慮しなければならない事項の一部です。詳細についてはホワイトペーパー「API主導の接続性」をご一読ください。