手に負えない API のスプロールを制御するためのテクニック

ゲッティイメージズ

API の大規模なポートフォリオを放置すると、企業にとって急速に大きな問題となり、多額の費用がかかる可能性があります。 明確に定義された API 戦略と標準化がなければ、アプリケーションは簡単に制御不能になり、API の無秩序な拡大を引き起こす可能性があります。

API のスプロール化が発生すると、冗長なアプリケーション機能に対する重複した開発作業などの非効率性が発生し、メンテナンスに多額の投資が必要になり、システムの複雑さが増大する可能性があります。 多くの消費者にとって下位互換性の必要性は、非常に複雑で費用がかかる場合があります。 真実の情報源が複数あるとデータの競合が発生する可能性があり、その結果、エクスペリエンスが低下し、曖昧さが生じ、採用率が低下する可能性があります。

この記事では、ソフトウェア チームが API のスプロール化を防ぐために、または必要に応じて、すでに誤って管理されている API ポートフォリオの制御を取り戻すために実装できるいくつかの包括的な戦略を検討します。

API の野放しな急増を管理するには、全体の複雑さ、変更コスト、緊急メンテナンスを最小限に抑えるために、ソフトウェア チームによる集中的な取り組みが必要です。

API のスプロールへの対処は、オペレーションとリソース消費に対する API の全体的な影響範囲を決定することから始まります。 多くの場合、API は組織内とその境界外の両方でソフトウェア エンティティと対話できます。 API の影響範囲は、内部または外部を問わずコンシューマーが API と明示的に統合されている場合に制限されることがよくあります。

公開されている API は、管理が非常に複雑になる可能性があります。 影響範囲による分類 (組織の制御を超えたコンポーネントやエンドポイントが多数含まれる可能性がある) に加えて、単一のパブリック API で複数のデータ形式、セキュリティ標準、通信プロトコルを組み込むことができます。 そのため、契約およびプロトコルの実装中に断片化の範囲を特定することが不可欠です。

場合によっては、API はライフサイクル全体にわたってシステム間で移行する必要があります。 スムーズな移行パスを可能にするために、ソフトウェア チームは移行前に API を準備し、望ましい状態を確実に維持する必要があります。 移行の問題を軽減するには、API が一括ではなく時間をかけてゆっくり移行するように移行を調整することも必要になる場合があります。 この点に関して便利な基本的な API バージョン管理テクニックがいくつかあります。たとえば、古いコントラクトが非推奨になっている間に消費者が新しいバージョンに移行できるようにするなどです。 チームは、人気のあるランタイム用にアクセス可能なライブラリを作成したり、新しい API 用の互換性レイヤーを作成したり、消費者固有の機能フラグを追加してシームレスな移行をサポートしたりすることもできます。

既存の状況と影響を十分に理解したら、その後のステップでは既存の標準を統合することに重点を置く必要があります。 このステージは 3 つの「サブステップ」に分けて実行できます。これについては以下で説明します。

チームは、環境全体にわたる API の使用を定期的に測定し、分析する必要があります。 API コンシューマーに対する制御がまったく存在しないか、ほとんど存在しない領域では、モックなどの機能をサポートする API 管理ツールまたはプラットフォームの支援が必要になる場合があります。 コアとなる公開領域、重要な機能、およびすべての既存の API 形式を特定します。

大規模で管理されていないポートフォリオ内の API は、情報ソースや開発作業の重複につながる冗長な動作を示すことがよくあります。 API 分類と、おそらくより重要なこととして、管理責任について強力なドメイン境界を引くことにより、ソースの曖昧さをなくすことが重要です。 これには、古い API の「統合バージョン」である新しい API を作成するか、冗長であると考えられる既存の API を廃止するか、単に既存の API のコントラクトを更新して範囲を狭めることが必要になる場合があります。

機能の統合が行われたら、ビジネス側のニーズと目標に沿った最終的な規約を確立することが重要であり、最終的には移行や新規開発への道筋を描くことになります。 これらの関係を文書化して図式化することは、契約構造や基礎となるプロトコルなどについて広範な合意を構築するという点で大いに役立ちます。