Les limites et les quotas protègent l'infrastructure Google contre les processus automatisés qui utilisent l'API Reports de manière inappropriée. Les requêtes excessives d'une API peuvent être dues à une simple faute de frappe ou à un système mal conçu qui effectue des appels d'API inutiles. Quelle que soit la cause, le blocage du trafic d'une source spécifique une fois qu'il atteint un certain niveau est nécessaire pour la santé globale du système Google Workspace. Cela permet de s'assurer que les actions d'un développeur ne peuvent pas avoir d'impact négatif sur la communauté au sens large.
Dans le cas peu probable où votre requête API échoue, vous recevrez un code d'état HTTP. Le code d'état 403 contient des informations d'erreur concernant une entrée incorrecte, et le code d'état HTTP 503 contient des informations d'erreur indiquant quels quotas d'API ont été 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 effectuées dans un délai fixe, envoyez-les en parallèle ou utilisez plusieurs threads dans votre application Java ou C#. Par exemple, vous pouvez demander de petits lots d'e-mails provenant de différents utilisateurs plutôt que d'ajouter ou de supprimer simultanément de nombreux e-mails d'un seul utilisateur simultanément. Dans le cas des threads, essayez de commencer par 10 threads, un thread par e-mail utilisateur. Notez que la recommandation concernant les threads présente 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 produiront.
Pour toutes les erreurs basées sur le temps (maximum de N éléments pendant N secondes par thread), en particulier les erreurs de code d'état 503, nous vous recommandons que votre code intercepte l'exception et, à l'aide d'un algorithme de backoff exponentiel, attende un court délai avant de réessayer l'appel ayant échoué. Dans un exemple d'API Reports pour un thread, vous pouvez attendre cinq secondes et réessayer 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 cinq secondes à dix secondes et réessayez votre appel ayant échoué. Définissez également une limite de tentatives. Par exemple, réessayez une requête cinq à sept fois avec des délais différents avant que votre application ne renvoie une erreur à l'utilisateur.
Limites
| Catégories de limites d'API | Limites |
|---|---|
| Fréquences RPS et RPD des rapports | 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 Admin SDK
de votre projet Google Cloud.
Si ces limites sont dépassées, le serveur renvoie un code d'état HTTP 503 code. Utilisez l' algorithme de backoff exponentiel lorsque vous réessayez vos requêtes. |
Limites supplémentaires pour activities.list |
L'API activities.list est limitée à 250
requêtes de filtre par minute (15 000 requêtes de filtre par heure). Une requête de filtre
est une requête API qui contient au moins l'un des paramètres de requête
suivants :
|
| Catégories de quotas d'API | Quotas |
| maxResults | Le nombre d'enregistrements listés sur chaque page de la réponse d'une API est compris entre 0 et 1 000. La valeur par défaut est de 1 000 enregistrements. |
Autres types de limites
| 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 est également compatible avec le format Atom. |
| Requêtes non autorisées | Google n'autorise pas les requêtes non autorisé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 les requêtes. |
| Messages d'avertissement |
|
Bonnes pratiques pour activities.list
La
activities.list
est censée être utilisée pour les enquêtes d'audit. Pour des performances optimales, votre requête doit inclure une plage temporelle à l'aide des
startTime et endTime paramètres. Des plages temporelles plus étroites
entraînent des délais de réponse beaucoup plus rapides. Cette méthode n'est pas
destinée à la récupération de journaux d'audit à volume élevé. Si vous épuisez régulièrement
votre quota de requêtes de filtre activities.list, envisagez les
options suivantes :
- Configurez l'exportation des journaux Google Workspace vers BigQuery et utilisez les puissantes API de requête de BigQuery pour récupérer et analyser les données dont vous avez besoin sans aucune contrainte de quota d'API.
- Utilisez des requêtes sans filtre avec une plage temporelle et effectuez un filtrage côté client (c'est-à-dire, effectuez la logique de filtrage dans votre application) au lieu d'utiliser des requêtes de filtre. Cela vous permet de dépasser la limite de 250 requêtes de filtre par minute,mais vous êtes toujours soumis à la limite de 2 400 requêtes par minute par utilisateur et par projet Google Cloud.