APIのタイプと構築するタイプを決定する方法

アプリケーションプログラミングインタフェースは、一般的にAPIと呼ばれ、データを公開し、企業によるシステム、アプリケーション、デバイス、およびデータセットへの接続を可能にします。意図されたユースケース、APIにアクセスして使用するユーザー、接続する必要があるシステムやデータセットなど、さまざまな要素にもとづいて、プロジェクトに対してどのタイプのAPIが最適に機能するかを理解することが重要です。効果的なAPIパフォーマンスとAPI管理のためには、アーキテクチャの構築および設計に最適なAPIのタイプを決定することが不可欠です。

目的別のAPIのタイプ

組織が突然、APIの必要性を決定することは稀です。ほとんどの場合、アイデア、用途、イノベーション、および他のシステムやデータセットへの接続が必要なユースケースを特定することから始めます。

APIは、統合の必要のあるシステムと、データセットの間の接続を可能にする手段として導入されます。

組織では、社内でのコアシステムの機能の公開から、顧客向けのモバイルアプリの有効化まで、目的に応じてさまざまなタイプのAPIが使用されます。MuleSoftのAPI主導の接続性アプローチには、APIの3つのカテゴリーが含まれます。

  • システムAPI:システムAPIは、レコードのコアシステムから組織内にデータを公開します。APIがデータを公開する重要なシステムの例としては、ERP、顧客および請求システム、専用データベースなどがあります。 
  • プロセスAPI:プロセスAPIは、単一のシステムまたはシステム全体でデータをやり取りして形成し、データのサイロ化を防ぎます。プロセスAPIを使用して、特定の事業目的に合わせて、データを組み合わせ、複数のシステムAPIのオーケストレーションを行うことができます。この例には、包括的な顧客ビュー、受注処理、および発送ステータスの作成などがあります。 
  • エクスペリエンスAPI:エクスペリエンスAPIは、システムAPIやプロセスAPIによって公開および確立されたデータやプロセスに、ビジネスコンテキストを付与します。エクスペリエンスAPIは、モバイルアプリケーションや顧客データ用の社内ポータルなどにデータを公開して、意図されたオーディエンスが利用できるようにします。


API管理戦略のタイプ

組織のAPIのユースケースを決定したら、次にこれらのAPIにアクセスするユーザーを決定します。ほとんどの場合、ユースケースと意図されたユーザーは密接に関連しています。たとえば、社内営業担当者とサービス担当者のために顧客データを公開したい場合、意図されたエンドユーザーは社内従業員になります。 

管理の方法とアクセスするユーザーにもとづいて、APIの3つのタイプを以下に示します。

外部API

外部APIには、組織にとって外部となる第三者(開発者やパートナーなど)がアクセスできます。多くの場合、革新的なアプリケーションや統合の開発をめざす世界中の開発者が、組織のデータやサービスにセルフサービスで容易にアクセスできるようにするために利用されます。
オープンAPIの例には、Google Maps APIがあります。これを(ライドシェアや宅配アプリなどの)サードパーティアプリケーション間で使用することで、位置情報の追跡とマッピングが可能になります。 

内部API

内部APIは、オープンAPIとは反対に、外部の利用者はアクセスできず、組織の社内開発者のみが利用できます。内部APIは、DevOpsやマイクロサービスアーキテクチャの導入から、レガシーモダナイゼーションやデジタルトランスフォーメーションまで、企業全体のイニシアチブを可能にします。これらのAPIの使用と再利用によって、組織の生産性、効率、俊敏性を向上させることができます。再利用可能な内部APIの例としては、コールセンターチームが、コールセンターアプリケーション内で使用する顧客情報のAPIを作成し、顧客の名前、連絡先情報、アカウント情報などにアクセスできるようにするなどです。チームはその後、この同じAPIを顧客向けWebアプリケーションやモバイルアプリケーションで再利用することができます。 

パートナーAPI

パートナーAPIは、内部APIと外部APIの中間に位置します。これは、専用の権限を持つ組織外のユーザーがアクセスできるAPIです。通常、この特別なアクセスは、戦略的なビジネスパートナーシップを促進する目的で特定の第三者に付与されます。 

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


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

APIを選択するためのもう1つの要素は、どのアーキテクチャのスタイルを採用するかです。特定の機能を必要としている場合、APIの意図された用途をサポートするのに最適なアーキテクチャのスタイルやパターンを選択することが不可欠です。これはAPI設計の判断になるため、より技術的な傾向のあるチームによって決定される傾向があります。 

この判断を下す前に、システムがオンプレミスかクラウドベースか、どのシステムやデータセットを使用する必要があるか、どのセキュリティプロトコルを実装する必要があるか、どの機能が必要かなど、確立されているインフラストラクチャについての基本を理解しておく必要があります。APIファーストの設計の精神ではレガシーのIT資産の現状によって機能や体験が左右されるのではなく、求められる機能やユーザーエクスペリエンスに応じて、レガシーのIT資産への変更が決定されます。 

APIにはさまざまなスタイルのアーキテクチャがあり、これらのスタイルの中でもデータ形式が異なります。以下に最も一般的なものを挙げます。 

  • REST: REST(Representational State Transfer)は、基礎となるネットワーキングプロトコルに組み込まれたコマンドにもとづいて、API提供者からAPI利用者の関連性を切り離すアーキテクチャスタイルです。クライアントは、読み取り、更新、共有、承認など、組み込まれたリンクやフォームを使用してアクションを実行します。HTMLがこのスタイルの例として最もよく知られており、他にも多くのAPI専用のフォーマットがあります(HAL、CollectionJSON、Sirenなど)。柔軟性、JSONやXMLなどの一般的なデータ形式への対応など、REST APIのメリットは数多くあります。
  • RPC: Remote Procedure Calls — or RPCs — typically require developers to execute specific blocks of code on another system. RPC-style remote invocation of procedures other systems usually requires developers to call those procedures by name. RPC is protocol-agnostic, which means it has the potential to be supported on many protocols, but also loses the benefits of using native protocol capabilities (e.g. caching). The proliferation of non-standard procedure names from one RPC API to the next results in tighter coupling between API consumers and providers which in turn overburdens developers involved in all aspects of an RPC-driven API ecosystem. RPC architectural patterns can be observed in popular API technologies such as SOAP, GraphQL, and gRPC.
  • イベント駆動/ストリーミング:イベント駆動型APIは、イベンテッドアーキテクチャ、リアルタイムアーキテクチャ、ストリーミングアーキテクチャ、非同期アーキテクチャ、またはプッシュアーキテクチャとも呼ばれ、APIの利用者の呼び出しを待たずにレスポンスを返します。呼び出しの代わりに、レスポンスはイベントの発生により開始されます。これらのサービスがイベントを公開し、このイベントをサブスクライブすることで、サービス上の値が変更されると更新を受け取ることができます。このスタイルには、リアクティブ、出版-購読型、イベント通知、CQRSなど、いくつかのバリエーションがあります。

私たちの周りには、このAPIパターンに適したあらゆる種類のイベントが数多くあります。以下に挙げたのは、そのごく一部です。

  • Twitterアカウントが新しいツイートを公開する。
  • 遠隔の温度計の温度が変わる。
  • 舗道のセンサーの上を自動車が通り過ぎる。
  • 防犯カメラが視野角の中で動きを検知する。
  • 心電図検査装置が不規則な心拍を検知する。
  • 非常ドアが開放される。
  • 火災警報器が煙を検知する。

効果的なAPIの設計と管理には、多くのことを検討する必要があります。上記の内容は、APIの設計、デプロイ、および管理の準備をする際に、組織で下す必要のあるさまざまな判断の一例を示すものです。詳細については、「API主導の接続性」からホワイトペーパーをダウンロードしてください。