Les limites et les quotas protègent l'infrastructure Google d'un processus automatisé qui utilise l'API Reports de manière inappropriée. Un nombre excessif de requêtes provenant d'une API peut résulter d'une faute de frappe ou d'un système mal conçu qui effectue des appels d'API inutiles. Quelle qu'en soit la cause, le blocage du trafic provenant d'une source spécifique dès qu'il atteint un certain niveau est nécessaire au bon fonctionnement général du système Google Workspace. Elle garantit que les actions d'un développeur ne peuvent pas avoir d'impact négatif sur l'ensemble de la communauté.
Dans le cas peu probable où votre requête API échouerait, vous recevrez une réponse avec code d'état HTTP. Un code d'état 403 contient des informations d'erreur relatives à une entrée incorrecte, tandis qu'un code d'état HTTP 503 contient des informations d'erreur indiquant les quotas d'API dépassés. Ces réponses permettent à votre application personnalisée de détecter ces erreurs et de prendre les mesures appropriées.
Si vos requêtes doivent être traitées dans un délai déterminé, envoyez-les en parallèle ou utilisez plusieurs threads dans votre application Java ou C#. Un exemple de demande parallèle consiste à demander des e-mails en petits lots de différents utilisateurs plutôt que d'ajouter ou de supprimer simultanément de nombreux e-mails d'un même utilisateur. Dans le cas des fils de discussion, essayez de commencer par 10 fils de discussion (un fil de discussion par adresse e-mail d'utilisateur). Notez que la recommandation de thread comporte des compromis et n'est pas utile dans toutes les situations d'API. Si le nombre de requêtes devient trop élevé, des erreurs de quota se produisent.
Pour toutes les erreurs temporelles (maximum de N éléments pour N secondes par thread), en particulier les erreurs de code d'état 503, nous vous recommandons d'intercepter l'exception avec votre code et, à l'aide d'un algorithme d'intervalle exponentiel entre les tentatives, attendez un court délai avant de relancer l'appel ayant échoué. Pour un thread, par exemple, l'API Reports doit attendre cinq secondes et relancer l'appel ayant échoué. Si la requête aboutit, répétez ce schéma pour les autres threads. Si la deuxième requête n'aboutit pas, votre application doit réduire la fréquence de la requête jusqu'à ce qu'un appel aboutisse. Par exemple, augmentez le délai initial de 5 secondes à 10 secondes, puis relancez l'appel ayant échoué. Définissez également un nombre maximal de tentatives. Par exemple, relancez une requête cinq à sept fois avec des délais différents avant que votre application ne renvoie une erreur à l'utilisateur.
| Catégories de limites d'API | Limites |
|---|---|
| Signaler les taux de RPS et de QPD | L'API limite le nombre de requêtes pour votre projet Google Cloud.
La valeur par défaut définie dans la console Google Cloud est de 2 400 requêtes par minute,par utilisateur et par projet Google Cloud.
Vous pouvez augmenter cette limite sur la page Quotas de l'API du SDK Admin de votre projet Google Cloud.
Si ces limites sont dépassées, le serveur renvoie un code d'état HTTP 503. Utilisez l'algorithme d'intervalle exponentiel entre les tentatives lorsque vous relancez vos requêtes. |
| Catégories de quotas d'API | Quotas |
| résultats max. | Le nombre d'enregistrements répertoriés sur chaque page de réponse d'une API est compris entre 1 et 1 000. La valeur par défaut est 1 000 enregistrements. |
| Autres types de limites | Limites et consignes |
|---|---|
| Format de données, par défaut | Le format de données par défaut est JSON. L'API prend également en charge le format Atom. |
| Demandes non autorisées | Google n'autorise pas les demandes non autorisées adressées à l'API. Une requête est considérée comme non autorisée si aucun jeton d'autorisation n'est fourni. Pour en savoir plus, consultez la section Autoriser des requêtes. |
| Messages d'avertissement |
|