API はクラウド ネイティブ アプリケーションの結合組織であり、アプリケーションのコンポーネント マイクロサービスが通信する手段です。 アプリケーションが成長し、拡張するにつれて、マイクロサービスと API の数も増加します。 これはほとんどの場合避けられない結果ですが、最新のアプリケーションの信頼性、スケーラビリティ、セキュリティの確保を担当するプラットフォーム運用チームにとっては大きな課題となります。 私たちはこの問題を「API スプロール」と呼んでおり、以前のブログ投稿でこれについて書きました。
API の拡散を解決するための最初の試みとして、組織は、自動化された API 検出および修復のためのツールを実装することで、トップダウン アプローチを試みる場合があります。 これは短期的には効果的ですが、API とマイクロサービスの構築と運用を担当するチームに過度の負担をかけることがよくあります。 セキュリティとコンプライアンスの問題に対処するために、既存のマイクロサービスと API を作り直すか、必要な承認を得るために困難なレビュー プロセスを経る必要があります。 このため、多くの大規模ソフトウェア組織は、適応型ガバナンスを使用して開発者に必要な自律性を与える分散型アプローチを採用しています。
土壇場で安全策を講じるよりも、問題に対するボトムアップのアプローチの方が長期的には効果的です。 さまざまなマイクロサービスやアプリケーション用の API を構築および運用するチームが最初に関与し、多くの場合、組織内のソフトウェア開発にAPI ファーストのアプローチを採用することから始めます。
API は何十年も前から存在しています。 しかし、それらはもはや単なる「アプリケーション プログラミング インターフェイス」ではありません。 本質的に、API は開発者インターフェースです。 他のユーザー インターフェイスと同様に、API には計画、設計、テストが必要です。 API ファーストとは、API を運用および使用するすべてのチームにわたって接続性とシンプルさの重要性を認識し、優先順位を付けることです。 ほとんどの場合は開発者である API 消費者のコミュニケーション、再利用性、機能性を優先します。
API ファーストへの道は数多くありますが、API ファーストの取り組みに乗り出すほとんどの企業にとって、ソフトウェア開発に対する設計主導のアプローチが最終目標となります。 実際には、このアプローチは、実装前に API が完全に定義されることを意味します。 作業は、API がどのように機能するかを設計し、文書化することから始まります。 チームは、結果として得られる成果物(多くの場合、 API 契約と呼ばれる)に基づいて、アプリケーションの機能をどのように実装するかを決定します。
NGINX 提供の O'Reilly の電子書籍『 Mastering API Architecture』の第 1 章で、耐久性と柔軟性を兼ね備えたソフトウェア開発への API ファースト アプローチをサポートするための設計手法について説明します。
API ファースト戦略は、アプリケーション エコシステムがモジュール式の再利用可能なシステムとして開始されることを保証するため、マイクロサービス アーキテクチャに最適です。 API ファーストのソフトウェア開発モデルを採用すると、開発者と組織の両方に次のような大きなメリットがもたらされます。
全体として、API ファーストのアプローチを採用することで、企業はより柔軟でスケーラブルかつ安全なマイクロサービス アーキテクチャを構築できるようになります。
一般的なエンタープライズ マイクロサービスおよび API 環境では、プラットフォーム運用チームが日々追跡できる以上のコンポーネントが稼働しています。 標準の機械可読 API 仕様を採用することで、チームは環境内で現在動作している API を理解し、監視し、意思決定を行うことができます。
共通の API 仕様を採用すると、API 設計フェーズでの関係者とのコラボレーションの改善にも役立ちます。 API 契約を作成し、それを標準仕様として正式に定めることで、API がどのように機能するかについてすべての関係者が共通の認識を持つことができます。 また、再利用可能な定義と機能をチーム間で共有することも容易になります。
現在、3 つの一般的な API 仕様があり、それぞれがほとんどの種類の API をサポートしています。
REST API は現在運用中の API の大部分を占めており、OpenAPI 仕様は REST API の API 定義を記述する標準的な方法です。OpenAPI 仕様は、特定の API がどのように機能するかを記述する機械可読な契約を提供します。 OpenAPI 仕様は、NGINX を含むさまざまな API 管理および API ゲートウェイ ツールで広くサポートされています。このブログの残りの部分では、OpenAPI 仕様を使用していくつかの重要なユースケースを実現する方法に焦点を当てます。
OpenAPI 仕様は、JSON または YAML で API を定義するためのオープン ソース形式です。 次の簡単な API の例に示すように、幅広い API 特性を含めることができます。 ここでは、単純な HTTP GET
リクエストが、架空の食料品リストにあるアイテムのリストを返します。
オープンAPI: 3.0.0情報:
バージョン: 1.0.0
タイトル: 食料品リスト API
説明: OpenAPI 仕様を説明するサンプル API
サーバー:
url: https://api.example.io/v1
パス:
/list:
get:
説明: 買い物リストにあるもののリストを返します
応答:
'200':
説明: リストが正常に返されました
コンテンツ:
スキーマ:
タイプ: 配列
項目:
タイプ: オブジェクト
プロパティ:
item_name:
タイプ: 文字列
OpenAPI 仕様に準拠した定義は、人間と機械の両方が判読可能です。 つまり、各 API がどのように機能するかを文書化した単一の真実のソースが存在することを意味し、これは API を構築および運用するチームが多数ある組織では特に重要です。 もちろん、API を大規模に管理、統制、保護するには、API プラットフォーム内の他のツール (API ゲートウェイ、開発者ポータル、高度なセキュリティ) も OpenAPI 仕様をサポートしていることを確認する必要があります。
Mastering API Architectureの第 1 章では、OpenAPI 仕様を使用して REST API を設計する方法について詳しく説明します。
OpenAPI 仕様などの共通 API 仕様を使用すると、次のようないくつかの利点があります。
全体として、共通の API 仕様を使用すると、相互運用性、ドキュメント、テスト、セキュリティ、および API の段階的な進化を向上させることができます。
NGINX は、大規模な API の操作、監視、管理、セキュリティ保護を容易にする、軽量のクラウドネイティブ ツール セットを提供します。 たとえば、 F5 NGINX Management Suiteの一部であるAPI Connectivity Manager は、API 操作用の単一の管理プレーンを提供します。 これを使用すると、API ゲートウェイと開発者ポータルを構成および管理できます。 API ファーストのツールであるため、すべての機能は REST API 経由でアクセスでき、 DevOpsチームにとって CI/CD の自動化と統合が容易になります。
OpenAPI 仕様を使用すると、NGINX 製品を使用して次のことが可能になります。
API Connectivity Manager は OpenAPI 仕様を使用して、API の公開と管理を効率化します。 API 開発者は、NGINX Management Suite ユーザー インターフェイスまたは完全に宣言的な REST API を使用して、API ゲートウェイに API を公開できます。API は、API プロキシとしてゲートウェイに追加されます。API プロキシには、受信した API リクエストをバックエンド マイクロサービスに転送するために API ゲートウェイが必要とするすべてのイングレス、バックエンド、およびルーティング構成が含まれています。 Ansible などのツールを使用して簡単な CI/CD 自動化スクリプトを作成することにより、REST API を使用して API をコードとしてデプロイおよび管理できます。
OpenAPI 仕様を使用して API を公開する方法の詳細については、 API Connectivity Manager のドキュメントを参照してください。
ドキュメントの維持は、API チームにとって頭痛の種となることがよくあります。 しかし、開発者ポータル上の古いドキュメントも、API の無秩序な増加の大きな兆候です。 API Connectivity Manager は OpenAPI 仕様を使用してドキュメントを自動的に生成し、開発者ポータルに公開します。これにより、API 開発者の時間が節約され、API コンシューマーが常に必要なものを見つけられるようになります。 API 接続マネージャー ユーザー インターフェースまたは REST API を介して、OpenAPI 仕様ファイルを直接アップロードできます。
開発者ポータルに API ドキュメントを公開する詳細な手順については、 API Connectivity Manager のドキュメントを参照してください。
OpenAPI 仕様を使用して、NGINX Plus API ゲートウェイへの API リクエストが API のサポート内容に準拠しているかどうかを確認することもできます。 ポジティブ セキュリティ (許可するものを定義し、それ以外はすべてブロックするセキュリティ モデル) を適用することで、悪意のあるリクエストがバックエンド サービスの潜在的な脆弱性を調査するのを防ぐことができます。
執筆時点では、API Connectivity Manager を使用してNGINX App Protect WAF を構成することはできません。この機能は 2023 年後半に利用可能になる予定です。 ただし、 Instance Manager (別の NGINX Management Suite モジュール) と OpenAPI 仕様を使用して、WAF のカスタム ポリシーを記述することはできます。 詳細については、 NGINX App Protect WAFおよびインスタンス マネージャーのドキュメントを参照してください。
API セキュリティと脅威モデリング、および API ゲートウェイで認証と承認を適用する方法の詳細については、 『Mastering API Architecture 』の第 7 章を参照してください。
マイクロサービスとアプリケーションを構築するための API ファーストのアプローチは、組織にさまざまなメリットをもたらします。 OpenAPI 仕様 (または人間と機械の両方が判読可能な他の共通 API 仕様) に沿ってチームを調整することで、チーム間でのコラボレーション、コミュニケーション、運用が可能になります。
最新のアプリケーションは、複雑なクラウドネイティブ環境で動作します。 API を運用するための API ファースト アプローチを可能にするツールを導入することは、API ファースト戦略を実現するための重要なステップです。 NGINX を使用すると、OpenAPI 仕様を使用して、分散したチームや環境全体で API を大規模に管理できます。
NGINX Management Suite の 30 日間無料トライアルを開始します。これには、 API Connectivity Manager 、API ゲートウェイとしてのNGINX Plus 、API を保護するNGINX App Protectへのアクセスが含まれます。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"