Cette page a été traduite par l'API Cloud Translation.

Limites d'utilisation

Étant donné que l'API Google Chat est un service partagé, nous appliquons des quotas et des limites pour nous assurer qu'elle est utilisée de manière équitable par tous les utilisateurs et pour protéger les performances globales de Google Workspace.

Si vous dépassez un quota, vous recevrez une réponse avec le code d'état HTTP 429: Too many requests. Des vérifications supplémentaires de la limite de débit sur le backend Chat peuvent également générer la même réponse d'erreur. Si cette erreur se produit, vous devez utiliser un algorithme d'attente exponentielle et réessayer plus tard. Tant que vous respectez les quotas par minute indiqués dans les tableaux suivants, le nombre de requêtes que vous pouvez effectuer par jour n'est pas limité.

Deux types de quotas s'appliquent aux méthodes de l'API Chat: les quotas par espace et par projet.

Quotas par espace

Les quotas par espace limitent le débit des requêtes dans un espace donné et sont partagés entre toutes les applications Chat qui agissent dans cet espace en appelant les méthodes de l'API Chat listées pour chaque quota.

Le tableau suivant détaille les limites de requête par espace:

Quota par espace	Méthodes de l'API Chat	Limite (par période de 60 secondes, partagée entre toutes les applications Chat de l'espace)
Lectures par minute	`media.download` `spaces.get` `spaces.members.get` `spaces.members.list` `spaces.messages.get` `spaces.messages.list` `spaces.messages.attachments.get` `spaces.messages.reactions.list`	900
Écritures par minute	`media.upload` `spaces.delete` `spaces.patch` `spaces.messages.create` (Des limites supplémentaires s'appliquent aux webhooks entrants) `spaces.messages.delete` `spaces.messages.patch` `spaces.messages.reactions.create` `spaces.messages.reactions.delete`	60

Quota par espace

Méthodes de l'API Chat

Limite (par période de 60 secondes, partagée
entre toutes les applications Chat de l'espace)

Lectures par minute

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

Écritures par minute

media.upload

spaces.delete

spaces.patch

spaces.messages.create (Des limites supplémentaires s'appliquent aux webhooks entrants)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

Quotas par projet

Les quotas par projet limitent le débit des requêtes pour un projet Google Cloud et s'appliquent donc à une seule application Chat qui appelle les méthodes de l'API Chat spécifiées pour chaque quota.

Le tableau suivant détaille les limites de requête par projet. Vous trouverez également ces limites sur la page Quotas.

Quota par projet	Méthodes de l'API Chat	Limite (par 60 secondes)
Écritures de messages par minute	`spaces.messages.create` `spaces.messages.patch` `spaces.messages.delete`	3000
Nombre de lectures de messages par minute	`spaces.messages.get` `spaces.messages.list`	3000
Nombre d'écritures de membres par minute	`spaces.members.create` `spaces.members.delete`	300
Nombre de lectures de membres par minute	`spaces.members.get` `spaces.members.list`	3000
Écritures d'espaces par minute	`spaces.setup` `spaces.create` `spaces.patch` `spaces.delete`	60
Nombre de lectures de l'espace par minute	`spaces.get` `spaces.list` `spaces.findDirectMessage`	3000
Nombre d'attachements écrits par minute	`media.upload`	600
Nombre de lectures d'une pièce jointe par minute	`spaces.messages.attachments.get` `media.download`	3000
Nombre d'écritures de réactions par minute	`spaces.messages.reactions.create` `spaces.messages.reactions.delete`	600
Nombre de lectures de réactions par minute	`spaces.messages.reactions.list`	3000

Limites d'utilisation supplémentaires

Des limites de quota supplémentaires s'appliquent à la création d'espaces de type GROUP_CHAT ou SPACE (à l'aide de la méthode spaces.create ou spaces.setup). Créez moins de 35 espaces par minute et 800 espaces par heure de ce type. Les espaces de type DIRECT_MESSAGE ne sont pas soumis à ces limites de quota supplémentaires.

Un trafic API élevé ciblant le même espace peut déclencher des limites internes supplémentaires qui ne sont pas visibles sur la page Quotas.

Résoudre les erreurs de quota basées sur le temps

Pour toutes les erreurs basées sur le temps (maximum de N requêtes par X minutes), nous vous recommandons de faire en sorte que votre code intercepte l'exception et utilise un intervalle de temps exponentiel tronqué pour vous assurer que vos appareils ne génèrent pas de charge excessive.

L'intervalle exponentiel entre les tentatives est une stratégie standard de gestion des exceptions pour les applications réseau. Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Si les requêtes échouent toujours, il est important que les délais entre les requêtes augmentent au fil du temps jusqu'à ce que la requête aboutisse.

Exemple d'algorithme

Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Exemple :

Envoyez une requête à l'API Google Chat.
Si la requête échoue, attendez 1 + random_number_milliseconds et effectuez une nouvelle tentative.
Si la requête échoue, attendez 2 + random_number_milliseconds et effectuez une nouvelle tentative.
Si la requête échoue, attendez 4 + random_number_milliseconds et relancez la requête.
Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.
Continuez d'attendre et de relancer la requête jusqu'à atteindre le nombre maximal de tentatives, mais n'augmentez pas le temps d'attente entre les tentatives.

où :

Le temps d'attente est défini sur min(((2^n)+random_number_milliseconds), maximum_backoff), avec n incrémenté de 1 pour chaque itération (requête).
random_number_milliseconds correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cela permet d'éviter les cas où de nombreux clients se retrouvent synchronisés pour une raison quelconque et effectuent tous une nouvelle tentative en même temps, en envoyant des requêtes par vagues synchronisées. La valeur de random_number_milliseconds est recalculée après chaque nouvelle tentative de la requête.
La valeur maximum_backoff est généralement définie sur 32 ou 64 secondes. La valeur appropriée dépend du cas d'utilisation.

Le client peut continuer à effectuer des nouvelles tentatives après avoir atteint le délai maximum_backoff. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Par exemple, si un client utilise un délai maximum_backoff de 64 secondes, une fois celui-ci atteint, il peut effectuer une nouvelle tentative toutes les 64 secondes. À un certain moment, vous devez empêcher les clients d'effectuer des tentatives à l'infini.

Le temps d'attente entre les nouvelles tentatives et le nombre de tentatives dépendent de votre cas d'utilisation et des conditions du réseau.

Demander une augmentation du quota par projet

En fonction de l'utilisation des ressources de votre projet, vous pouvez demander une augmentation de quota. Les appels d'API effectués par un compte de service sont considérés comme utilisant un seul compte. La demande d'augmentation de quota ne garantit pas l'approbation. Les augmentations importantes peuvent nécessiter plus de temps pour être approuvées.

Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que vous utilisez Google Cloud de plus en plus, vous devrez peut-être augmenter vos quotas. Si vous prévoyez une augmentation notable de l'utilisation, vous pouvez anticiper cette évolution en demandant des ajustements de quota sur la page Quotas de la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :