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).

​https://blog.apisyouwonthate.com/api-versioning-has-no-right-way-f3c75457c0b7​

​

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.