Versioning
Dernière mise à jour
Dernière mise à jour
Etant donné que les APIs ReST sont conçues pour être utilisées par de multiples sources (clients mobiles / web / desktop / partenaires / public…), elles évoluent souvent à un rythme différent de celui des clients.
Pour s'adapter au changement, il y a trois principales approches :
Versioning par Media Type.
Versioning par URL.
Pas de versioning (la solution à privilégier tant que possible).
Le versioning par Media Type consiste à utiliser le comportement standard des headers HTTP Accept et Content-Type.
Le client indique alors la version de l’API qu’il supporte dans le header Accept :
Accept: application/vnd.wishtack.v3+json
L’API retourne alors les données dans la version correspondante avec le bon Media Type dans le header Content-Type.
Séduisant mais légèrement complexe à mettre en place.
Comment faire si la nouvelle version est implémentée dans un langage différent ou encore sur une plateforme différente ?
Vu l’obstacle de balancing posé par le versioning par Media Type, pourquoi ne pas utiliser un balancing standard en amont… mais lequel ?
Qui dit mieux ?
Nous serions alors obligé d’utiliser un connecteur pour effectuer le balancing.
Nous pourrions utiliser le path de l’URL et procéder au balancing en fonction du nom de domaine. Cela nécessite toujours un connecteur : mais c'est une approche un peu plus classique et plus facile à configurer.
Yes ! Le DNS ! NodeJS hosted on Amazon. Python hosted on Heroku. Python hosted on Heroku sur un monorépo avec l’API V2. Serverless functions sur un monorépo avec l’API V2 et V3.
