Les versions

Pour chaque endpoint, plusieurs versions de l’API sont disponibles. Le préfixe de version est spécifié au début de l’url de chaque endpoint.

Si l’on se réfère à la documentation Swagger, on peut voir que les endpoints de la section Elevation ont différents préfixes :

  • /1.0/

  • aucun préfixe : dans ce cas-là, ce sera la version la plus récente qui sera utilisée.

../_images/versions.png

En utilisant une version figée de l’API, comme la version 1.0, vous garantissez :

  • Une stabilité et de la prévisibilité : l’API ne sera pas perturbée par les changements futurs de l’API. Vous pouvez prévoir le comportement de votre application.

  • Une réduction de risques : vous évitez les éventuels bugs ou incomptabilités introduits par les mises à jour de l’API

  • Moins de dépendances externes et de maintenance : vous n’êtes pas obligé de vous adapter continuellement aux changements de l’API

En revanche, cela peut présenter quelques inconvénients :

  • Manque de nouvelles fonctionnalités : vous risques de manger de nouvelles fonctionnalités ou améliorations apportées par les versions ultérieures de l’API

  • Eventuelle obsolescence : A long terme, une version figée peut devenir obsolète, ce qui peut nécessiter une migration complexe vers une nouvelle version de l’API

En fin de compte, le choix entre une version figée et la version “latest” dépend de votre tolérance au risque, de la nature de votre application, et de la manière dont vous gérez les mises à jour et la maintenance. Il est courant d’utiliser une version figée dans les environnements de production critiques et de tester d’abord les nouvelles versions de l’API dans des environnements de développement ou de préproduction pour minimiser les risques potentiels.