Comment on page
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).
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+jsonL’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
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 4yr ago