次の方法で共有

マイクロサービス API とコントラクトの作成、進化、バージョン管理

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

PDF をダウンロードする

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

マイクロサービス API は、サービスとそのクライアント間のコントラクトです。 API コントラクトを解除しない場合にのみ、マイクロサービスを個別に進化させることができます。そのため、コントラクトは非常に重要です。 コントラクトを変更すると、クライアント アプリケーションまたは API ゲートウェイに影響します。

API 定義の性質は、使用しているプロトコルによって異なります。 たとえば、AMQP などのメッセージングを使用している場合、API はメッセージの種類で構成されます。 HTTP および RESTful サービスを使用している場合、API は URL と要求と応答の JSON 形式で構成されます。

ただし、最初のコントラクトについて熟考している場合でも、サービス API は時間の経過と同時に変更する必要があります。 その場合 (特に API が複数のクライアント アプリケーションによって使用されるパブリック API の場合) は、通常、すべてのクライアントに新しい API コントラクトへのアップグレードを強制することはできません。 通常、サービス コントラクトの古いバージョンと新しいバージョンの両方が同時に実行されるように、サービスの新しいバージョンを段階的にデプロイする必要があります。 そのため、サービスのバージョン管理の戦略を立てすることが重要です。

API に属性やパラメーターを追加する場合など、API の変更が小さい場合は、古い API を使用するクライアントは、新しいバージョンのサービスを切り替えて操作する必要があります。 必要な属性がない場合は既定値を指定でき、クライアントは追加の応答属性を無視できる場合があります。

ただし、サービス API に対して大きな変更と互換性のない変更を行う必要がある場合があります。 クライアント アプリケーションまたはサービスを強制的に新しいバージョンにすぐにアップグレードできない場合があるため、サービスでは一定の期間、古いバージョンの API をサポートする必要があります。 REST などの HTTP ベースのメカニズムを使用している場合、1 つの方法は、URL または HTTP ヘッダーに API バージョン番号を埋め込むことです。 その後、同じサービス インスタンス内で両方のバージョンのサービスを同時に実装するか、API のバージョンを処理する異なるインスタンスをデプロイするかを決定できます。 この機能の優れたアプローチは、さまざまな実装バージョンを独立したハンドラーに分離する Mediator パターン ( MediatR ライブラリなど) です。

最後に、REST アーキテクチャを使用している場合、 Hypermedia は、サービスのバージョン管理と進化可能な API の許可に最適なソリューションです。

その他のリソース

前へ次へ