Éviter le sondage
Vous devez vous abonner aux événements de webhook au lieu d’interroger l’API pour rechercher des données. Ce qui aidera votre intégration à rester dans la limite de débit d’API. Pour plus d’informations, consultez « AUTOTITLE ».
Formuler des demandes authentifiées
Les demandes authentifiées ont une limitation de débit primaire plus élevée que celles qui ne le sont pas. Pour éviter de dépasser la limitation de débit, il est donc recommandé de formuler des demandes authentifiées. Pour plus d’informations, consultez « AUTOTITLE ».
Éviter les demandes simultanées
Pour éviter de dépasser les limitations de débit secondaires, vous devez formuler des demandes en série plutôt que simultanément. Pour ce faire, vous pouvez implémenter un système de file d’attente pour les demandes.
Pause entre les demandes de changement
Si vous formulez un grand nombre de demandes , , ou , attendez au moins une seconde entre chaque demande. Cela vous aidera à rester en dessous des limitations de débit secondaires.
Gérer les erreurs de limitation de débit de manière appropriée
Si vous recevez une erreur de limite de débit, vous devez arrêter temporairement d’effectuer des demandes en fonction des instructions suivantes :
- Si l'en-tête de réponse est présent, vous ne devez pas réessayer votre demande avant le nombre de secondes spécifié.
- Si l’en-tête est , vous ne devez pas effectuer une autre demande avant la durée spécifiée par l’en-tête . L’en-tête est en secondes d’époque UTC.
- Sinon, attendez au moins une minute avant de réessayer. Si votre demande continue d'échouer en raison d'une limite de débit secondaire, attendez une durée exponentiellement croissante entre les nouvelles tentatives et levez une erreur après un nombre spécifique de nouvelles tentatives.
Continuer à effectuer des requêtes alors que vous êtes limité par le rate limit peut entraîner le bannissement de votre intégration.
Pour en savoir plus sur l’affichage de l’activité d’API d’une organisation, y compris les demandes qui ont dépassé les limites de débit principal, consultez Visualisation des informations sur l'API dans votre organisation.
Suivre les redirections
L’API REST GitHub utilise la redirection HTTP le cas échéant. Vous devez partir du principe que toute demande peut entraîner une redirection. La réception d’une redirection HTTP ne constitue pas une erreur, et vous devez suivre cette redirection.
Un code d’état indique une redirection permanente. Vous devez répéter votre demande à l’URL spécifiée par l’en-tête . En outre, vous devez mettre à jour votre code pour utiliser cette URL pour les demandes ultérieures.
Un code d’état ou indique une redirection temporaire. Vous devez répéter votre demande à l’URL spécifiée par l’en-tête . Toutefois, vous ne devez pas mettre à jour votre code pour utiliser cette URL pour les demandes ultérieures.
D’autres codes d’état de redirection peuvent être utilisés conformément aux spécifications HTTP.
Ne pas analyser manuellement les URL
De nombreux points de terminaison d’API retournent des valeurs d’URL pour les champs dans le corps de la réponse. Il est déconseillé d’essayer d’analyser ces URL ou de prévoir la structure des URL futures. Cela peut entraîner le dysfonctionnement de votre intégration si GitHub modifie la structure de l’URL à l’avenir. Au lieu de cela, il est recommandé de rechercher un champ qui contient les informations dont vous avez besoin. Par exemple, le point de terminaison permettant de créer un problème renvoie un champ (espace réservé) avec une valeur telle que (espace réservé) et un champ (espace réservé) avec une valeur telle que (espace réservé). Si vous avez besoin de connaître le numéro du problème, utilisez le champ au lieu d’analyser le champ .
De même, il est déconseillé d’essayer de construire manuellement des requêtes de pagination. Au lieu de cela, utilisez les en-têtes de lien pour déterminer quelles pages de résultats peuvent faire l’objet d’une demande. Pour plus d’informations, consultez « AUTOTITLE ».
Utiliser des demandes conditionnelles si nécessaire
La majorité des points de terminaison renvoient un en-tête (espace réservé), et un grand nombre d’entre eux renvoient également un en-tête (espace réservé). Vous pouvez utiliser les valeurs de ces en-têtes pour formuler des demandes conditionnelles . Si la réponse n’a pas changé, vous recevrez une réponse . L’établissement d’une requête conditionnelle n’est pas pris en compte dans la limite principale de votre débit si une réponse est renvoyée et que la requête a été effectuée avec un en-tête autorisé correct.
Par exemple, si une requête précédente a renvoyé une valeur d’en-tête (espace réservé) de (espace réservé), vous pouvez réutiliser l’en-tête (espace réservé) dans une requête ultérieure :
curl -H "Authorization: Bearer YOUR-TOKEN" https://api.github.com/meta --include --header 'if-none-match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
Par exemple, si une demande précédente a retourné la valeur pour l’en-tête , vous pouvez utiliser l’en-tête dans une demande ultérieure :
curl -H "Authorization: Bearer YOUR-TOKEN" https://api.github.com/repos/github/docs --include --header 'if-modified-since: Wed, 25 Oct 2023 19:17:59 GMT'
Les demandes conditionnelles pour les méthodes non sécurisées, telles que , , et ne sont pas prises en charge, sauf indication contraire dans la documentation d’un point de terminaison spécifique.
Ne pas ignorer les erreurs
Il est déconseillé d’ignorer les codes d’erreur et qui reviennent plusieurs fois. Au lieu de cela, vérifiez que vous interagissez correctement avec l’API. Par exemple, si un point de terminaison demande une chaîne et que vous transmettez une valeur numérique, vous recevrez une erreur de validation. De même, toute tentative d’accès à un point de terminaison non autorisé ou inexistant entraîne une erreur .
Le fait d’ignorer intentionnellement toutes les erreurs de validation peut entraîner la suspension de votre application pour abus.
Pour aller plus loin
- AUTOTITRE
- AUTOTITRE