はじめに
現代的なソフトウェアは、アプリケーション プログラミング インターフェイス (API) を利用しています。 あなたの組織が過去 1 年間に構築したアプリケーションを振り返ってみれば、ほとんどの機能が API を利用しているでしょう。 大きなスケールで見ると、これは、多くの組織には内部的に構築されたか、外部 API と統合された数百、数千、または数万個もの API が存在する可能性があることを意味します。 高まり続けているソフトウェアに対する需要と、これらのソフトウェアを支える基盤レイヤーとしての API の性質により、あなたのチームが使用することになる API の数は、急激ではないにしろ、増加することが予想されます。
シナリオ
Contoso Corporation は、API ファーストのアプローチを採用して、マイクロサービス アーキテクチャを実装している架空の会社です。 初期の頃は、この組織に存在する API を構築するチームは少数であり、多くの場合、構築を行ったのと同じチームがその API を使用していました。 時間が経過するにつれ、組織は成長し、現在では多くのチームが、内部と外部の両方で開発される API を作成し使用しています。 しかし、Contoso の API プラットフォーム エンジニアは、組織が API スプロール状態 (組織の API の数が指数関数的かつ制御不可能な形で増加する状態) に近づいていると報告し、以下を含むその他のダウンストリームの問題を予測しています。
API の検出可能性と再利性の低下 - 利用可能な API を明確に把握しないと、開発者は既存の機能をレプリケートする新しい API を作成してしまい、時間とリソースが無駄になる可能性があります。
管理されていないシャドウ API - ほとんどの開発者は、他のプロジェクトに移る際に、一部の API を分離して管理とメンテナンスを行うことをやめてしまう可能性があります。
セキュリティ上の脅威の可能性 – API プラットフォーム チームが組織のセキュリティ ポリシーを効果的に適用できず、脆弱でセキュリティで保護されていないエンドポイントが発生する可能性があります。
一貫性のない API 設計 - 開発者の一部が組織の統一された API 設計の原則に準拠する API を作成しなくなり、ロールアウトの後に発見された一貫性のない API を再設計するために、より多くの開発リソースを利用する必要が生じる可能性があります。
この時点で、API プラットフォーム チームは、組織がこの状態になるのを防ぐための効果的でシームレスなソリューションについてのブレーンストーミングを開始しました。 あなたの組織がより簡単な追跡とガバナンスのためにすべての API を一元化する戦略の採用も必要としている場合は、これはあなたにとって適切なモジュールです。
学習の目的
このモジュールでは、次のことを行います。
- Azure API Center とはどのようなもので、どのような恩恵をもたらすのかを理解します。
- API Center が、一元化された API インベントリ、ガバナンス、検出、使用によってどのように組織に力をもたらすのかを調べます。
- 自分の組織で Azure API Center の使用を開始する方法を理解します。
- Visual Studio Code などの開発者ツールとの高度な統合について調べます。