Partager via

Création, évolution et gestion de versions d’API et de contrats de microservice

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Architecture de microservices .NET pour les applications .NET conteneurisées - vignette de couverture du livre électronique.

Une API de microservice est un contrat entre le service et ses clients. Vous serez en mesure d’évoluer indépendamment d’un microservice uniquement si vous ne rompez pas son contrat d’API, c’est pourquoi le contrat est si important. Si vous modifiez le contrat, cela aura un impact sur 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 la messagerie, comme AMQP, l’API se compose des types de messages. Si vous utilisez des services HTTP et RESTful, l’API se compose des URL et des formats JSON de requête et de réponse.

Toutefois, même si vous avez soigneusement conçu votre contrat initial, une API de service devra évoluer au fil du temps. Dans ce cas, et surtout si votre API est une API publique consommée par plusieurs applications clientes, vous ne pouvez généralement pas forcer tous les clients à effectuer une mise à niveau vers votre nouveau contrat d’API. Vous devez généralement déployer de manière incrémentielle de nouvelles versions d’un service de manière à ce que les versions antérieures et nouvelles d’un contrat de service s’exécutent simultanément. Par conséquent, il est important d’avoir une stratégie pour le contrôle de version de votre service.

Lorsque les modifications de l’API sont petites, comme si vous ajoutez des attributs ou des paramètres à votre API, les clients qui utilisent une API plus ancienne doivent basculer et utiliser la nouvelle version du service. Vous pouvez peut-être fournir des valeurs par défaut pour tous les attributs manquants requis, et les clients peuvent ignorer les attributs de réponse supplémentaires.

Toutefois, vous devez parfois apporter des modifications majeures et incompatibles à une API de service. Étant donné que vous ne pouvez pas forcer la mise à niveau immédiate des applications clientes ou des services vers la nouvelle version, un service doit prendre en charge les versions antérieures de l’API pendant une certaine période. Si vous utilisez un mécanisme basé sur HTTP tel que REST, une approche consiste à incorporer le numéro de version de l’API dans l’URL ou dans un en-tête HTTP. Vous pouvez ensuite décider d’implémenter les deux versions du service simultanément au sein de la même instance de service ou de déployer différentes instances qui gèrent chacune une version de l’API. Une bonne approche pour cette fonctionnalité est le modèle Médiateur (par exemple, bibliothèque MediatR) pour dissocier les différentes versions d’implémentation en gestionnaires indépendants.

Enfin, si vous utilisez une architecture REST, Hypermedia est la meilleure solution pour la gestion de version de vos services et l’autorisation d’API évolutives.

Ressources supplémentaires

PrécédentSuivant