Versioning
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).
API Versioning Has No "Right Way"

Versioning par Media Type

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 ?
  • Nous serions alors obligé d’utiliser un connecteur pour effectuer le balancing. https://github.com/Kong/kong/issues/402

Versioning par URL

Vu l’obstacle de balancing posé par le versioning par Media Type, pourquoi ne pas utiliser un balancing standard en amont… mais lequel ?
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 : https://getkong.org/docs/0.13.x/proxy/#request-path mais c'est une approche un peu plus classique et plus facile à configurer.
🧐
👍
Qui dit mieux ?
Yes ! Le DNS ! https://v1.api.wishtack.com NodeJS hosted on Amazon. https://v2.api.wishtack.com Python hosted on Heroku. https://v3.api.wishtack.com Python hosted on Heroku sur un monorépo avec l’API V2.https://v4.api.wishtack.com Serverless functions sur un monorépo avec l’API V2 et V3.
Dernière mise à jour 2yr ago