API成熟度モデルとは

一部のAPI成熟度フレームワークでは、セキュリティー、発見可能性、保守性、プラットフォーム・エンジニアリングなど特定の側面を重視しています。Kong社、Tyk社、Curity社などのAPI Managementベンダーは、自社のソリューションに沿ったAPI成熟度モデルを提供しており、顧客がこれらのプラットフォームを採用する際の進捗を測るのに役立っています。他のモデルはより範囲が広く、あらゆるプロトコルやアーキテクチャーに適用できます。

アプリケーション・プログラミング・インターフェース（API）は、個別のサービスやアプリケーション間の接続を容易にし、インターネットの重要な柱であり、開発者がゼロから構築するのではなく、サードパーティのテクノロジーやデータ・ソースを活用できるように支援します。また、組織内の参考情報、データ・セキュリティー、ガバナンスを統合し、内部デプロイメントやチーム間のコミュニケーションを合理化することもできます。複数のAPIをライブラリ、UIツール、その他のコンポーネントとともにパッケージ化することで、ソフトウェア開発キット（SDK）を形成することができます。SDKは、開発者が標準化されたアプリケーションを迅速かつ高い信頼性を持って構築するためのツールセットです。

API成熟度モデルは、組織がより洗練され堅牢なAPIシステムを開発し、効率性、セキュリティ、相互運用性を向上させるために、特定の構造的・技術的イノベーションや戦略的なベスト・プラクティスを特定・記述します。これらは、組織がAPI開発を加速するにあたり、どのイノベーションを優先すべきかを決定するのに役立つロードマップとして機能します。

最も広く引用されているフレームワークの1つであるRichardson成熟度モデルは、APIがRESTful の原則に準拠しているかどうかを4つの成熟度レベルで評価し、最も高い階層が完全にRESTfulなシステムを表します。

2000年、コンピューター科学者のRoy Fieldingは、統一されたインターフェース、クライアントとサーバーの分離、ステートレス、キャッシュ可能性、階層化システムなどの主要な機能を促進するアーキテクチャー・スタイルであるRESTを導入しました。これらの機能を組み合わせることで、組織内の拡張性、効率性、柔軟性が向上し、大規模に実装すると、よりオープンで、Resilient® で、安全なインターネットの実現に貢献します。最新のイテレーションでは、多くの場合、情報を転送するためにHTTPが使用され、このデータを整理するために人間が読み取れるJSON形式が使用されますが、他のプロトコルや形式も使用できます。

2008年、ソフトウェア・エンジニアのLeonard Richardson氏は、REST API設計の適応性とレジリエンスを向上させるために組織が実装できる具体的な技術変更を特定するモデルを使用して、このフレームワークをベースに構築しました。Richardsonの成熟度モデル（RMM）は、「URI、HTTP、ハイパーメディア（HTML）という3つのウェブ・テクノロジーを、パッケージ契約ではなく3つの個別のテクノロジーとして見ることを推奨しています」とRichardson氏はIBMに考察する。このフレームワークでは、「これらのテクノロジーがあることを考えると、非常に人気があり、あらゆるプログラミング言語で広くサポートされている」と、それぞれを段階的に実装することの実際的なメリットが示されています。

Richardson成熟度モデルでは、参考情報の実装を優先し、各参考情報に一意の識別子を割り当てることを推奨する一般的なREST原則に従って、各参考情報に個別のURIを割り当てます。また、RMMは、ある時点でのAPIについての静的かつ事前定義された記述を提示する説明文書ではなく、APIの現在の状態を捉える応答文書の使用を推奨しています。このモデルは一般にHTTPベースのウェブ・アプリケーションに適用されますが、概念的なフレームワークとしては、IoT（モノのインターネット）ネットワークやデータ・パイプラインなどの他のコンテキストでも使用できます。

リチャードソン成熟度モデルは、非RESTfulアーキテクチャから完全なRESTfulアーキテクチャーまで、異なる成熟度を区別するために4つのレベルを使用します。

レベルゼロは非RESTfulな設計を表し、単一のエンドポイント（"/api "など）と単一のコマンド（通常はPOST）を主要な機能とします。レベルゼロは実装が簡単ですが、動詞、URI、ステータス・コードなどのHTTPの最も強力な主要な機能を使用できません。代わりに、HTTPは単にトランスポート・メカニズムとしてのみ使用され、すべての操作の詳細がメッセージ本文自体に追加されます。

XMLベースのリモート・プロシージャ・コール（RPC）パターンが歴史的にこの方式を採用してきたため、批評家たちはこの方式を「POXの沼」（POX：plain old XML）と呼んでいます。構造が欠如し、サービス間の明確な境界線がないと、機能やデータが混乱しやすく、密結合になりやすいという考え方があります。レベルゼロでは、APIには検出可能な参考情報を識別したり公開したりする機能がないため、APIの利用者は何が利用可能か事前に知る必要があります。単一のエンドポイントではそれ自体に関する情報を共有できないため、開発者はスケーリング、バージョン管理、トラブルシューティングに苦労する可能性があります。

レベル1では、それぞれが異なる参考情報を表すことができる複数のURIを導入します。ただし、次に進むHTTP動詞（通常はPOST）のみを使用し続けています。クライアントは、一般的な「エンドポイント」エンドポイントを操作する代わりに、特定の参考情報に対応するエンドポイント（たとえば、電子商取引における"/products"、"/carts"、"/invoices"）を呼び出すことができるようになりました。ただし、クライアントは通常、事前定義されたHTTP動詞のセットを使用するのではなく、リクエスト自体の本文を通じて運用上の意図やアクションを伝える必要があります。

このアプローチにより、参考情報間の境界線がより明確になり、クライアントが利用できる参考情報に関して曖昧さが減ります。しかし、URIを呼び出すための標準化された形式がないため、開発者はどのアクションが実行できるかについて、容易に混乱する可能性があります。レベル1では、実際には開発者が"/productsUpdate"や"/productsDelete"などの個々のアクションに対して新しいエンドポイントを作成する場合があるため、時間の経過とともに煩雑になる可能性があります。このアプローチでは、URIが徐々に蓄積され、ロールアウトとバージョン管理がより困難になる可能性があります。

最後に、このモデルでは、参考情報には個別のURIが割り当てられるものの、どのアクションを解釈または実行できるかを明らかにすることができないため、開発者は外部APIのドキュメンテーションへの依存度がさらに高まります。

レベル2では、開発者がデータやサービスを操作するために使用できる標準化された動詞のセットであるHTTPメソッドを追加します。多くの構成では、クライアントは4つの基本コマンド（作成、読み取り、更新、削除）を使用して、各エンドポイントで異なるアクションを実行できます。ヘッダーは、API呼び出し中にコンテンツ・タイプ、条件付き要件、認証情報などの追加情報を伝達するために使用できます。

このアプローチは、レベル1およびレベル0と比較して、より効率的で組織的です。ユーザーがAPIの機能とクライアントとのやり取り方法を把握しているからです。しかし、APIはこの情報をリアルタイムで伝えることができません。ユーザーは外部の開発者ポータルを通じてのみ各APIについて知ることができるため、見つけやすさが低下します。この静的なアプローチは、APIのドキュメンテーションが現在の機能と一致しない場合、不整合につながる可能性もあります。

現在、ほとんどの組織のAPIエコシステムは、レベル2で運用されています。これは、このレベルが予測可能性、効率性、アクセシビリティーのバランスをとるためです。また、組織はキャッシュ（頻繁に使用される参考情報をローカルに保管し、すぐに取得できるようにする）などのHTTPの独自の機能を活用できるようになり、性能の大幅な向上につながります。

レベル3では、アプリケーション状態のエンジンとして HATEOAS（ハイパーメディア）を導入します。クライアントがAPI呼び出しを行うと、APIは最新のブラウザーの動作方法など、さまざまなアクションや関連用語の動的リストを使って応答します。これらのアクションと条件は帯域内で伝達されるため、開発者はそれらについて知るために外部ドキュメンテーションを参照する必要がありません。ハイパーメディアベースのアーキテクチャーは、外部クライアントがサービスの使用方法を事前に学習しなくても簡単にサービスにアクセスできるため、相互運用性も促進されます。

同時に、ハイパーメディア・コントロールは実行時により大きな複雑さをもたらします。「クライアントは、事前にプログラムされた方法で反応するだけでなく、サーバーから受信するドキュメントを読み取って、次のリクエストについての決定を下すためにそれらの文書を参照してください」とRichardson氏は述べました。

ハイパーメディア機能の構築と保守は、ハイパーメディアの動的構造により、よりコストと時間がかかる場合があります。APIは、さらなるアクションのための一連のリンクを使用してクライアントの要求に応答しますが、これは運用上の負担が大きくなります。また、多くのクライアント・プラットフォームはハイパーメディアをサポートしていないため、組織がHATEOASを採用する場合、外部ユーザーはこれらのサービスにアクセスする前に互換性のあるツールを見つけなければならない可能性があります。

現在、HATEOASはオープン性と相互運用性を促進するため、ライブラリー、非営利団体、市場連合、または革新的な企業（業種・業務を破壊しようとしている組織）で最も頻繁に使用されているとRichardson氏は述べています。ハイパーメディアは、APIエコシステムについて事前の知識がないユーザーでも、APIやアクションを簡単に見つけられるようになるため、社内で使用する場合にも効果的です。一部の企業では、成長段階ではハイパーメディアAPIを提供し、製品の収益化を開始した後でアクセスを制限することがあります。

業種・業務は特定のユースケース向けにGraphQLやgRPCなどの代替手段へとますますシフトしています。Postmanの『State of the API』レポートによると、開発者の93%が何らかの形でRESTfulウェブサービスを利用していると答え、3分の1がGraphQLを使用し、14%がgRPCを使用しています。GraphQLは、複数のマイクロサービス（異なる環境でホストされているサービスなど）からのリクエストをインテリジェントに取得し、それらを1つの応答にコンパイルして、効率を高め、オーバープロビジョニングやプロビジョニング不足を防ぐことができます。一方、gRPCは、ストリーミング、テレメトリー、および高性能と低遅延が最大の関心事であるその他のユースケースに最適です。

GraphQLとgRPCはハイパーメディアの動的な性質を再現できませんが、どちらのアーキテクチャーも効率性とスキーマ管理に関連する問題点により正確に所在地できるため、組織によっては、ハイパーメディアの完全な制御よりもこれらの実装を優先することもあります。

Richardson成熟度モデルでは、あるAPIの成熟度レベルから次の成熟度レベルに移行すると、設計面での課題と技術的な課題の両方が生じる可能性があります。このプロセスには、多くの場合、複数のURI（レベル1）と複数のHTTPメソッド（レベル2）に対応するようにサーバー・コードをリファクタリングすることが含まれます。これは、ルーティング・ルール、データベース・インタラクション、テスト、ドキュメンテーション、コントローラーを更新することで実現されます。

組織は、現在のエンドポイントをカタログ化し、RESTfulの制約に従って変更できるエンドポイントを特定し、必要な参考情報と動詞をマッピングすることから始めることができます。開発者は、移行中にクライアントからの通話が中断されないように、組織の現在のビルドの上に新しいバージョンを構築する場合があります。包括的なエラー・コードのセットは、ユーザーが新しいAPIエンドポイントをナビゲートする方法を学び、追加のドキュメンテーションを参照せずにエラーをトラブルシューティングするのにも役立ちます。

RMMがRESTfulシステムにおける特定の技術実装に焦点を当てているのに対し、組織モデルはより広い視野を持ち、企業が一貫性、参考情報の最適化、適応性を促進する共通の原則に沿って調整するのに役立ちます。戦略的成熟度フレームワークは組織によって異なる場合がありますが、一般的なアプローチには以下の4つの層が含まれています。

基本的またはアドホックなエコシステムでは、組織は一貫性のあるAPI開発フレームワークの下で作業するのではなく、目の前の懸念に対応します。開発者は、限られた集中管理で必要に応じてAPIを作成および廃止するため、不整合やガバナンス、セキュリティー、オブザーバビリティーの問題につながる可能性があります。現在のAPIの性能をほとんど洞察していないと、チームは効果的に参考情報を割り当てたり、将来の計画を立てたりすることができません。

標準化されたAPIエコシステムは、一貫したドキュメンテーション、命名規則、エラー・コード、設計パターンを導入します。API Gatewayを使用して、認証、承認、およびその他の一元化されたAPIセキュリティーを適用できます。開発者は、組織のガバナンス構造内でAPIを自信を持って追加、削除、維持でき、コンポーネントをシームレスに再利用したり、適応させたりすることができます。クライアントは、開発者ポータルと統合されたオンボーディングを通じて、利用可能なサービスを簡単に見つけて知ることができるため、全体的なAPIの導入が促進されます。

しかし、現時点ではAPIの性能とセキュリティーを把握する仕組みがほとんどないため、チームはエコシステムの監視を維持するのに苦労する可能性があります。たとえば、組織は特定のAPIクラスター内のセキュリティー侵害、バージョン管理エラー、認証の問題に気づいていない可能性があります。

マネージド・フレームワークは、テレメトリー・データ、KPI、その他のメトリクスを使用してAPIの性能をより詳細に把握します。たとえば、監視システムは、クライアントが過度のAPIダウンタイムに直面した場合に開発者に警告を発し、サーバーの過負荷、ネットワークの停止、コードの不整合、その他の問題など、根本的な問題の特定を支援することができます。

管理対象エコシステムには、より高度なAPIガバナンス・インフラストラクチャーも主要な機能ている場合があります。これにより、チームの自律性を維持しながら、管理を担当しているAPIを利害関係者が明確に理解できるようになります。最後に、管理されたエコシステムは正式なライフサイクル管理プロセスを導入し、API は設計、開発、保守、バージョン管理、廃止全体にわたって監視されます。しかしこの段階では、API Managementがより広範なビジネス目標にどのように貢献するかについて、組織はまだ一貫性のあるビジョンを欠いている可能性があります。

最適化された戦略的フレームワークは、ガバナンス、標準化、ライフサイクル管理、メトリクス、およびセキュリティーのベスト・プラクティスを長期的な事業計画と組み合わせたものです。ネットワーク全体を監視することで、組織は効率的に拡張および参考情報を割り当て、変化する市場状況に動的に対応できます。組織はAPIを技術的なコンポーネントとしてのみ考えるのではなく、より広範なビジネス目標に役立つAPIをデプロイできます。戦略的フレームワークは、組織が先進的なロードマップとストラテジーを策定し、イノベーションを加速し、運用効率を向上させるのに役立ちます。

組織は、特定の問題点や運用上の焦点に所在地ためにAPI成熟度モデルを作成する場合があります。一般的な重点分野は以下の通りです。

これらの成熟度モデルは、エクスペリエンスの向上に貢献する特定のプロトコル、プラクティス、標準の採用など、API設計原則に焦点を当てています。RMMは設計ベースのフレームワークの一例ですが、他のモデルではGraphQL、gRPC、およびその他のアーキテクチャー・スタイルに重点を置いている場合があります。

ガバナンス・モデルは、組織がAPIエコシステムの制御と監視をどの程度維持できるかに焦点を当てています。最上位の組織では、利害関係者の自律性を維持しながら、高いコンプライアンス、データ品質、セキュリティーを維持します。

ガバナンスベースのフレームワークでは、自動チェックと検証プロセスが組み込まれているかどうかなど、APIエコシステムの適用メカニズムの品質も考慮されます。一方、オーナーシップ・モデルではAPIを特定のチームに割り当てて、すべてのAPIが考慮されます。

セキュリティに重点を置いた成熟度フレームワークは、API ネットワークがセキュリティのベスト・プラクティスを順守しているかどうかを評価します。初期段階では、組織はAPIキーや基本的なHTTP認証に依存しているかもしれませんが、どちらもきめ細かな制御が欠けており、漏洩に対しても脆弱です。Advancedシステムでは、トークンベースの認証と承認、およびゼロトラスト・アクセスが導入される場合があります。最も洗練されたフレームワークは、OAuthや OpenID Connect（OIDC）認証プロトコルの使用など、IDおよびアクセス管理の原則に準拠しています。

APIドキュメントは、開発者が特定のAPIを使用および統合する方法を説明するテクニカル・ガイドです。ドキュメンテーションには、チュートリアル、コード例、リリース・ノート、許容される呼び出しパラメーターなどを含めることができます。

組織は当初、APIドキュメンテーションを作成および維持するための標準化されたプロセスがなく、開発者は各APIの機能についてほとんど洞察が得られないかもしれません。上位層では、OpenAPISpecification（OAS）やAPI青写真など、API仕様を説明するための標準化された形式が導入される場合があります。成熟したAPIフレームワークには自動化も組み込まれている場合があり、各ロールアウトとともにドキュメンテーションが自動的に更新されるようになります。

オブザーバビリティーに重点を置いた成熟度モデルは、組織がマイクロサービス全体にわたるデータ収集メカニズムの洗練度を追跡するのに役立ちます。基本的なシステムでは、テレメトリーやメトリクスを使用して組織がエラーを特定することはできても、長期的なデータの傾向を特定することはできません。

より複雑なプラットフォームでは、レイテンシー、リクエスト率、その他の関連するメトリクスを事前に追跡して、組織がダウンタイム、不整合、その他の問題に事前に対応できるようにします。最上位層では、組織は大まかなデータ・パターンを特定し、将来のAPI開発の指針となる実行可能な洞察を得ることができます。