À propos du contrôle de version de l’API
L’API REST GitHub Enterprise Server est une version gérée. Le nom de la version de l’API est basé sur la date à laquelle la version de l’API a été publiée. Par exemple, la version de l’API 2022-11-28 a été publiée sur Mon, 28 Nov 2022.
Tous les changements cassants seront publiés dans une nouvelle version de l’API. Les changements cassants sont des modifications qui peuvent potentiellement arrêter une intégration. Les changements cassants incluent :
- suppression d’une opération entière
- suppression ou changement de nom d’un paramètre
- suppression ou changement de nom d’un champ de réponse
- ajout d’un nouveau paramètre obligatoire
- rendre obligatoire un paramètre précédemment facultatif
- modification du type d’un paramètre ou d’un champ de réponse
- suppression des valeurs d’énumération
- ajout d’une nouvelle règle de validation à un paramètre existant
- modification des exigences d’authentification ou d’autorisation
Tous les changements additifs (non cassants) seront disponibles dans toutes les versions d’API prises en charge. Les changements additifs sont des modifications qui ne doivent pas interrompre une intégration. Les changements additifs sont les suivants :
- ajout d’une opération
- ajout d’un paramètre facultatif
- ajout d’un en-tête de demande facultatif
- ajout d’un champ de réponse
- ajout d’un en-tête de réponse
- ajout de valeurs d’énumération
Lorsqu’une nouvelle version d’API REST est publiée, la version précédente de l’API est prise en charge pendant au moins 24 mois supplémentaires après la publication de la nouvelle version de l’API.
À propos du contrôle de version GitHub Enterprise Server et du contrôle de version d’API REST
Les versions GitHub Enterprise Server sont dissociées des versions d’API REST. Vous pouvez mettre à niveau votre version GitHub Enterprise Server, mais conserver la même version d’API REST, tant que la version de l’API est incluse dans la version GitHub Enterprise Server. De même, vous pouvez mettre à niveau votre version d’API REST sans mettre à jour votre version GitHub Enterprise Server, tant que la nouvelle version d’API REST que vous choisissez est disponible pour votre version GitHub Enterprise Server.
Les notes de publication GitHub Enterprise Server indiquent quand une version d’API REST n’est plus prise en charge. Pour plus d’informations, consultez « Notes de publication ».
Spécification d’une version d’API
Vous devez utiliser l’en-tête X-GitHub-Api-Version pour spécifier une version d’API. Par exemple :
curl --header "X-GitHub-Api-Version:2022-11-28" https://api.github.com/zen
Les requêtes sans l’en-tête X-GitHub-Api-Version utilisent par défaut la version 2022-11-28.
Si vous spécifiez une version d’API qui n’est plus prise en charge, vous recevrez une erreur 400.
Mise à niveau vers une nouvelle version de l’API
Avant de procéder à la mise à niveau vers une nouvelle version d’API REST, vous devez lire le journal de modifications des changements cassants qui correspond à la nouvelle version de l’API pour comprendre les changements cassants inclus et pour en savoir plus sur la mise à niveau vers cette version de l’API. Pour plus d’informations, consultez « Changements cassants ».
Lorsque vous mettez à jour votre intégration pour spécifier la nouvelle version de l’API dans l’en-tête X-GitHub-Api-Version , vous devez également apporter les modifications nécessaires pour que votre intégration fonctionne avec la nouvelle version de l’API.
Une fois votre intégration mise à jour, testez votre intégration pour vérifier qu’elle fonctionne avec la nouvelle version de l’API.
Versions d'API prises en charge
Les versions d’API REST suivantes sont actuellement prises en charge :
2022-11-28
Vous pouvez également faire en sorte qu’une demande d’API obtienne toutes les versions d’API prises en charge. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les métadonnées ».