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 appelle inutilement l'API. Quelle qu'en soit la cause, il est nécessaire de bloquer le trafic provenant d'une source spécifique dès qu'il atteint un certain niveau afin de préserver l'état global 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 échouerait, vous recevrez un code d'état HTTP en réponse. Un code d'état 403 contient des informations sur les erreurs d'entrée incorrectes, tandis qu'un code d'état HTTP 503 contient des informations sur les erreurs indiquant les quotas d'API qui 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 traitées dans un délai fixe, envoyez-les en parallèle ou utilisez plusieurs threads dans votre application Java ou C#. Par exemple, il est préférable de demander de petits lots d'e-mails provenant de différents utilisateurs plutôt que d'ajouter ou de supprimer de nombreux e-mails d'un même utilisateur simultanément. Dans le cas des fils de discussion, essayez de commencer par 10 fils, un par adresse e-mail d'utilisateur. Notez que la recommandation de thread 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 pour N secondes par thread), en particulier les erreurs de code d'état 503, nous vous recommandons de faire en sorte que votre code détecte l'exception et, à l'aide d'un algorithme d'intervalle exponentiel entre les tentatives, attende un court délai avant de réessayer l'appel ayant échoué. Un exemple d'API Reports pour un thread consiste à 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 échoue, votre application doit réduire la fréquence des requêtes jusqu'à ce qu'un appel réussisse. Par exemple, augmentez le délai initial de cinq secondes à dix secondes, puis réessayez d'appeler. Définissez également une limite de nouvelles 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.
Limites
| Catégories de limites d'API | Limites |
|---|---|
| Rapporter les taux de RPS et de RPD | 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. Utilisez l'algorithme d'intervalle exponentiel entre les tentatives lorsque vous relancez vos requêtes. |
Limites supplémentaires pour activities.list |
L'API activities.list impose une limite supplémentaire de 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 des données, par défaut | Le format de données par défaut est JSON. L'API est également compatible avec le format Atom. |
| Demandes 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 Autoriser les requêtes. |
| Messages d'avertissement |
|
Bonnes pratiques pour activities.list
La méthode activities.list est censée être utilisée pour les investigations d'audit.
Pour des performances optimales, votre requête doit inclure une plage de dates à l'aide des paramètres startTime et endTime. Plus les plages horaires sont étroites, plus les délais de réponse sont courts.
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 filtrage 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 de dates et effectuez le filtrage côté client (c'est-à-dire en appliquant la logique de filtrage dans votre application) au lieu d'utiliser des requêtes avec 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.