Limite du nombre de nœuds
Pour passer la validation de schéma, tous les appels d’API GraphQL doivent respecter les standards suivants :
- Les clients doivent fournir un argument
firstoulastsur toute connexion. - Les valeurs de
firstetlastdoivent être comprises entre 1 et 100. - Des appels individuels ne peuvent pas demander plus de 500 000 nœuds au total.
Calcul des nœuds dans un appel
Les deux exemples suivants montrent comment calculer le nombre total de nœuds dans un appel.
-
Requête simple :
query { viewer { repositories(first: 50) { edges { repository:node { name issues(first: 10) { totalCount edges { node { title bodyHTML } } } } } } } }Calcul :
50 = 50 repositories + 50 x 10 = 500 repository issues = 550 total nodes
-
Requête complexe :
query { viewer { repositories(first: 50) { edges { repository:node { name pullRequests(first: 20) { edges { pullRequest:node { title comments(first: 10) { edges { comment:node { bodyHTML } } } } } } issues(first: 20) { totalCount edges { issue:node { title bodyHTML comments(first: 10) { edges { comment:node { bodyHTML } } } } } } } } } followers(first: 10) { edges { follower:node { login } } } } }Calcul :
50 = 50 repositories + 50 x 20 = 1,000 pullRequests + 50 x 20 x 10 = 10,000 pullRequest comments + 50 x 20 = 1,000 issues + 50 x 20 x 10 = 10,000 issue comments + 10 = 10 followers = 22,060 total nodes
Limite du taux principal
L’API GraphQL affecte des points à chaque requête et limite les points que vous pouvez utiliser dans un délai spécifique. Cette limite permet d'éviter la mauvaise utilisation et les attaques par déni de service, et garantit que l'API reste disponible pour tous les utilisateurs.
L'API REST dispose également d'une limite de débit primaire distincte. Pour plus d’informations, consultez « Limites de débit pour l'API REST ».
En général, vous pouvez calculer votre limite de débit primaire pour l'API GraphQL en fonction de votre méthode d'authentification :
- Pour les utilisateurs : 5 000 points par heure par utilisateur. Cela inclut les demandes effectuées avec un personal access token ainsi que les demandes effectuées par un GitHub App ou OAuth app au nom d’un utilisateur qui a autorisé l’application. Les demandes effectuées au nom d'un utilisateur par une GitHub App appartenant à une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 10 000 points par heure. De même, les demandes effectuées en votre nom par une OAuth app détenue ou approuvée par une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 10 000 points par heure si vous êtes membre de l'organisation GitHub Enterprise Cloud.
- Pour les installations GitHub App hors GitHub Enterprise Cloud organization ou enterprise : 5 000 points par heure par installation. Les installations qui ont plus de 20 référentiels reçoivent 50 points supplémentaires par heure pour chaque référentiel. Les installations d'une organisation comptant plus de 20 utilisateurs reçoivent 50 points supplémentaires par heure et par utilisateur. La limite de débit ne peut pas dépasser 12 500 points par heure. La limite de débit pour les jetons d’accès utilisateur (par opposition aux jetons d’accès d’installation) est dictée par la limite de débit principale pour les utilisateurs.
- Pour les installations GitHub App sur une GitHub Enterprise Cloud organisation ou entreprise : 10 000 points par heure par installation. La limite de débit pour les jetons d’accès utilisateur (par opposition aux jetons d’accès d’installation) est dictée par la limite de débit principale pour les utilisateurs.
- Pour OAuth apps : 5 000 points par heure ou 10 000 points par heure si l’application appartient à une organisation GitHub Enterprise Cloud. Cela s’applique uniquement lorsque l’application utilise son ID client et sa clé secrète client pour demander des données publiques. La limite de débit pour les jetons d'accès OAuth générés par une OAuth app est dictée par la limite de débit primaire pour les utilisateurs.
- Pour
GITHUB_TOKENles flux de travail GitHub Actions : 1 000 points par heure par dépôt. Pour les demandes adressées aux ressources appartenant à un compte d'entreprise sur GitHub.com, la limite est de 15 000 points par heure par référentiels.
Vous pouvez vérifier la valeur de point d’une requête ou calculer la valeur de point attendue, comme décrit dans les sections suivantes. La formule de calcul des points et de la limite de débit est susceptible de changer.
Vérification de l'état de votre limite de débit
Vous pouvez utiliser les en-têtes envoyés avec chaque réponse pour déterminer l'état actuel de votre limite de débit primaire.
| Nom de l'en-tête | Description |
|---|---|
x-ratelimit-limit | Le nombre maximum de points que vous pouvez utiliser par heure |
x-ratelimit-remaining | Le nombre de points restants dans la fenêtre de limite de débit actuelle |
x-ratelimit-used | Le nombre de points que vous avez utilisés dans la fenêtre de limite de débit actuelle |
x-ratelimit-reset | Heure à laquelle la fenêtre de limite de débit actuelle se réinitialise en secondes d'époque UTC. |
x-ratelimit-resource | Ressource de la limite de débit par rapport à laquelle la requête a été comptabilisée. Pour les requêtes GraphQL, cela sera toujours graphql. |
Vous pouvez également contacter l’objet rateLimit afin de vérifier votre limite de débit. Dans la mesure du possible, il est préférable d'utiliser les en-têtes de réponse relatifs à la limite de débit plutôt que d'interroger l'API pour vérifier votre limite de débit.
query {
viewer {
login
}
rateLimit {
limit
remaining
used
resetAt
}
}
| Champ | Description |
|---|---|
limit | Le nombre maximum de points que vous pouvez utiliser par heure |
remaining | Le nombre de points restants dans la fenêtre de limite de débit actuelle |
used | Le nombre de points que vous avez utilisés dans la fenêtre de limite de débit actuelle |
resetAt | Heure à laquelle la fenêtre de limite de débit actuelle se réinitialise en secondes d'époque UTC. |
Retour de la valeur de point d’une requête
Vous pouvez retourner la valeur de point d’une requête en interrogeant le cost champ surrateLimit l’objet :
query {
viewer {
login
}
rateLimit {
cost
}
}
Prédiction de la valeur de point d’une requête
Vous pouvez également calculer approximativement la valeur de point d’une requête avant d’effectuer la requête.
- Ajoutez le nombre de demandes nécessaires pour assurer chaque connexion unique dans l’appel. Supposons que chaque demande atteigne les limites de l’argument
firstoulast. - Divisez le nombre par 100 et arrondissez le résultat au nombre entier le plus proche pour obtenir le coût d’agrégation final. Cette étape normalise les grands nombres.
Remarque
La valeur minimale d'un appel à l'API GraphQL est de 1 .
Voici un exemple de calcul de requête et de score :
query {
viewer {
login
repositories(first: 100) {
edges {
node {
id
issues(first: 50) {
edges {
node {
id
labels(first: 60) {
edges {
node {
id
name
}
}
}
}
}
}
}
}
}
}
}
La satisfaction de cette requête nécessite 5 101 :
- Bien que nous retournions 100 dépôts, l’API doit se connecter au compte de la visionneuse une fois pour obtenir la liste des dépôts. Ainsi, les demandes de dépôts = 1
- Bien que nous retournions 50 problèmes, l’API doit se connecter à chacun des 100 dépôts pour obtenir la liste des problèmes. Ainsi, les demandes de problèmes = 100
- Bien que nous retournions 60 étiquettes, l’API doit se connecter à chacun des 5 000 problèmes potentiels pour obtenir la liste des étiquettes. Ainsi, les demandes d’étiquettes = 5 000
- Total = 5 101
Une division par 100 et un arrondi nous donnent le score final de la requête : 51
Limites de débit secondaires
Outre les limitations de débit primaires, GitHub applique les limitations de débit secondaires pour éviter les abus et de conserver l’API disponible pour tous les utilisateurs.
Vous pouvez rencontrer une limitation de débit secondaire si vous :
- Effectuez trop de demandes simultanées. Plus de 100 requêtes simultanées ne sont autorisées. Cette limite est partagée entre l’API REST et l’API GraphQL.
- Effectuez trop de demandes à un point de terminaison unique par minute. Plus de 900 points par minute sont autorisés pour les points de terminaison d’API REST, et pas plus de 2 000 points par minute sont autorisés pour le point de terminaison de l’API GraphQL. Pour plus d’informations sur les points, consultez Calcul des points pour la limitation de débit secondaire.
- Effectuez trop de demandes par minute. Plus de 90 secondes de temps processeur par 60 secondes de temps réel sont autorisées. Plus de 60 secondes de ce temps processeur peuvent être pour l’API GraphQL. Vous pouvez estimer approximativement le temps processeur en mesurant le temps de réponse total pour vos demandes d’API.
- Effectuez trop de requêtes qui consomment un nombre excessif de ressources de calcul pendant une courte période.
- Créez trop de contenu sur GitHub dans un court laps de temps. En général, pas plus de 80 demandes de génération de contenu par minute et pas plus de 500 demandes de génération de contenu par heure ne sont autorisées. Certains points de terminaison contiennent des limites de création de contenu inférieures. Les limites de création de contenu incluent les actions effectuées sur l’interface web GitHub ainsi que via l’API REST et l’API GraphQL.
Ces limitations de débit secondaires sont susceptibles de changer sans préavis. Vous pouvez également rencontrer une limitation de débit secondaire pour des raisons non déclarées.
Calcul de points pour la limitation de débit secondaire
Certaines limitations de débit secondaires sont déterminées par les valeurs de points des demandes. Pour les demandes GraphQL, ces valeurs de point sont distinctes des calculs de valeurs de point pour la limitation de débit primaire.
| Requête | Points |
|---|---|
| Demandes GraphQL sans mutations | 1 |
| Demandes GraphQL avec mutations | 5 |
La plupart des demandes GET, HEAD et OPTIONS de l’API REST | 1 |
La plupart des demandes POST, PATCH, PUT, ou DELETE de l’API REST | 5 |
Certains points de terminaison d’API REST comportent un coût de point différent qui n’est pas partagé publiquement.
Dépassement de la limite de débit
Si vous dépassez votre limite de taux principal, l’état de la réponse sera toujours 200, mais vous recevrez un message d’erreur et la valeur de x-ratelimit-remainingl’en-tête sera 0. Vous ne devez réessayer votre requête qu'après le délai indiqué par l'en-tête x-ratelimit-reset.
Si vous dépassez une limite de débit secondaire, le statut de la réponse sera 200 ou 403, et vous recevrez un message d'erreur indiquant que vous avez atteint une limite de débit secondaire. Si l'en-tête de réponse retry-after est présent, vous ne devez pas réessayer votre demande avant le nombre de secondes spécifié. Si l'en-tête x-ratelimit-remaining est 0, vous ne devez pas réessayer votre demande avant la durée spécifiée par l'en-tête x-ratelimit-reset (en secondes 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.
La poursuite des demandes pendant que vous êtes limité peut entraîner l'interdiction de votre intégration.
Rester en dessous de la limite de débit
Pour éviter de dépasser une limite de débit, vous devez suspendre au moins 1 seconde entre les demandes mutatives et éviter les demandes simultanées.
Vous devriez également vous abonner à des événements webhook au lieu d'interroger l'API pour obtenir des données. Pour plus d’informations, consultez « Documentation sur les webhooks ».
Vous pouvez également parcourir le journal d'audit pour voir les requêtes d'API. Ce journal peut vous aider à résoudre les problèmes d'intégrations qui dépassent la limite de débit. Pour plus d’informations, consultez « Streaming de journaux d’audit pour votre entreprise ».
Délais d'attente
Si GitHub met plus de 10 secondes à traiter une requête API, GitHub mettra fin à la requête et vous recevrez une réponse d’expiration de délai et un message indiquant que « Nous n’avons pas pu répondre à votre requête à temps ».
GitHub se réserve le droit de modifier le délai d’expiration pour protéger la vitesse et la fiabilité de l’API.
Vous pouvez vérifier l’état de l’API GraphQL sur githubstatus.com pour déterminer si le délai d’expiration est dû à un problème avec l’API. Vous pouvez également essayer de simplifier votre demande ou d’essayer votre demande ultérieurement. Par exemple, si vous demandez un grand nombre d’objets dans une seule requête, vous pouvez essayer d’en demander moins, répartis sur plusieurs requêtes.