Partager via

Création, évolution et version des contrats et des API de microservices

  • Article

Conseil

Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.

Télécharger le PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Une API de microservice est un contrat entre le service et ses clients. Vous ne pouvez pas faire évoluer indépendamment un microservice si son contrat d’API est rompu. C’est pourquoi le contrat est si important. Tout changement apporté au contrat impacte vos applications clientes ou votre passerelle API.

La nature de la définition de l’API dépend du protocole que vous utilisez. Par exemple, si vous utilisez une messagerie telle qu’AMQP, l’API comprend les types de messages. Si vous utilisez des services HTTP et RESTful, l’API comprend les URL et les formats JSON de requête et de réponse.

Toutefois, même si votre contrat initial est l’aboutissement d’une réflexion, une API de service doit changer au fil du temps. Quand cela se produit, vous ne pouvez généralement pas forcer tous les clients à effectuer une mise à niveau vers votre nouveau contrat d’API, surtout s’il s’agit d’une API publique consommée par plusieurs applications clientes. Dans la plupart des cas, vous devez déployer par incrément les nouvelles versions d’un service en faisant en sorte que les anciennes et les nouvelles versions du contrat de service s’exécutent simultanément. Il est donc important de disposer d’une stratégie pour la gestion de versions de votre service.

Si vous apportez des changements minimes à l’API, comme l’ajout d’attributs ou de paramètres, il est recommandé que les clients qui utilisent une API antérieure passent à la nouvelle version du service. Il est possible que vous puissiez fournir des valeurs par défaut pour tous les attributs obligatoires manquants et que les clients ignorent les attributs de réponse en trop.

Toutefois, vous pouvez parfois être amené à apporter des changements majeurs à une API de service qui débouchent sur des incompatibilités. Dans l’éventualité où vous ne pourriez pas forcer les applications ou services clients à passer tout de suite à la nouvelle version, un service doit prendre en charge les anciennes versions de l’API pendant un certain temps. Si vous utilisez un mécanisme HTTP, par exemple REST, il existe une approche qui consiste à incorporer le numéro de version de l’API dans l’URL ou dans un en-tête HTTP. Vous pouvez ensuite soit implémenter simultanément les deux versions du service dans la même instance de service, soit déployer des instances distinctes gérant des versions différentes de l’API. Une bonne approche vis-à-vis de cette fonctionnalité consiste à utiliser le modèle Médiateur (par exemple, la bibliothèque MediatR) pour découpler les différentes versions de l’implémentation en gestionnaires indépendants.

Enfin, si vous utilisez une architecture REST, Hypermedia constitue la meilleure solution pour la gestion de versions de vos services et la prise en charge d’API évolutives.

Ressources supplémentaires

PrécédentSuivant