Skip to main content
L’API Chataigne inclut sa version majeure dans le chemin de l’URL :
Il n’existe ni alias sans version ni en-tête de version. Incluez toujours /v1 dans l’URL appelée par votre intégration.

​
Ajouts compatibles

Des ajouts compatibles peuvent être publiés dans v1. Ils comprennent :
  • De nouveaux endpoints ou paramètres de requête facultatifs.
  • De nouveaux champs facultatifs dans les réponses.
  • De nouvelles variantes de ressources ou de codes d’erreur.
  • De nouveaux en-têtes de réponse.
  • Des validations assouplies ou un champ auparavant requis devenu facultatif.
Écrivez des clients compatibles avec ces évolutions : lisez les champs nécessaires, ignorez ceux que vous ne connaissez pas et ne supposez pas qu’un objet JSON possède un ensemble fixe de clés.

​
Ruptures de compatibilité

Les changements susceptibles d’empêcher un client correct de fonctionner nécessitent une nouvelle version majeure. Par exemple :
  • Supprimer ou renommer un endpoint ou un champ.
  • Modifier le type ou la signification d’un champ existant.
  • Ajouter un champ de requête obligatoire.
  • Modifier le comportement de la pagination, de l’authentification ou des statuts d’erreur.
  • Supprimer une valeur d’énumération documentée.
Lorsqu’une nouvelle version majeure est introduite, ses changements et les étapes de migration sont publiés dans le Journal des modifications. Les versions existantes fonctionnent en parallèle pendant une période de migration communiquée.

​
Recommandations pour les clients

  • Conservez le segment de version dans une seule URL de base configurable.
  • Validez les champs nécessaires à votre intégration, mais acceptez les champs supplémentaires.
  • Traitez les identifiants de ressources et les curseurs comme des chaînes opaques.
  • Surveillez le journal des modifications et testez une nouvelle version majeure avant de basculer le trafic de production.
Node.js