À propos du contrôle de version de l’API
L’API GitHub REST est versionné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 2026-03-10 de l’API a été publiée le Tue, 10 Mar 2026.
Les modifications disruptives sont des changements qui peuvent potentiellement interrompre une intégration. Les changements disruptifs seront publiés dans une nouvelle version d'une API. Nous fournirons un préavis avant de publier des changements cassants. Les modifications disruptives 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.
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:2026-03-10" 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 410 Gone réponse.
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 ruptures de compatibilité qui correspond à la nouvelle version de l’API pour comprendre les modifications critiques incluses et obtenir plus d'informations sur la mise à niveau vers cette version spécifique 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 des modifications requises 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.
Version de l’API en cours de clôture
Les versions d’API sont prises en charge pendant 24 mois après la publication d’une version plus récente de l’API.
Bien qu’une version se trouve dans sa fenêtre de prise en charge, mais approche en cours de clôture, GitHub inclut les en-têtes suivants dans les réponses d’API pour vous aider à préparer la migration :
Deprecation— Date à laquelle la version de l’API sera en cours de clôturemise en forme sous forme de date HTTP par RFC 7231. Par exemple :Wed, 27 Nov 2019 14:34:29 GMT.Sunset— Date à laquelle la version de l’API sera complètement supprimée (mis hors service), après laquelle les demandes retourneront une410 Goneréponse. Suit RFC 8594. Par exemple :Fri, 27 Nov 2020 14:34:29 GMT.
Une fois la fenêtre de support terminée :
- Les demandes qui spécifient une version d’API en cours de clôture reçoivent une
410 Goneréponse. - Les demandes qui ne spécifient pas de version d’API utilisent par défaut la version la plus ancienne prise en charge, et non la version en cours de clôture. Si vous vous appuyez sur des demandes non modifiées, vous pouvez observer des modifications comportementales à mesure que les versions antérieures sont supprimées de la prise en charge.
Pour plus d’informations sur la migration vers une version plus récente de l’API, consultez Changements cassants.
Exceptions au contrôle de version standard
Dans de rares cas, GitHub des modifications peuvent être apportées en dehors de la cadence normale de contrôle de version de l’API. Il s’agit d’interventions exceptionnelles qui ne modifient pas les garanties de contrôle de version standard pour la plupart des intégrateurs.
Problèmes de sécurité, de disponibilité et de fiabilité
Les vulnérabilités de sécurité critiques, les risques d’exposition aux données ou les problèmes de fiabilité graves peuvent nécessiter des modifications en dehors de la planification normale des mises en production. GitHub peut publier une version d’API non planifiée, des correctifs rétroportés pour les versions prises en charge, ou dans de rares cas, introduire un changement disruptif dans une version existante afin de protéger les utilisateurs et l’intégrité de la plateforme.
GitHub communiquera ces modifications par le biais des notes de publication, des journaux de modification et une communication directe expliquant ce qui a changé et pourquoi. Dans la mesure du possible, un avis préalable sera fourni. L’action immédiate peut être effectuée sans préavis préalable si nécessaire.
Services à faible utilisation
Pour certains services avec une utilisation très faible, GitHub peut déprécier les fonctionnalités en dehors du processus de contrôle de version standard. Dans ces cas, GitHub communiquera l’intention et contactera directement les intégrateurs concernés.
Versions d'API prises en charge
Les versions d’API REST suivantes sont actuellement prises en charge.
| Version de l’API | Date de fin de support |
|---|---|
2026-03-10 | Not yet scheduled |
2022-11-28 | March 10, 2028 |
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 ».