Par défaut,l'API EMM Google Play est limitée à 60 000 requêtes par minute.
Si vous dépassez le quota, l'API EMM Google Play renvoie HTTP 429 Too Many Requests.
Pour vous assurer de ne pas dépasser les limites d'utilisation indiquées et d'offrir une expérience optimale à vos utilisateurs, pensez à appliquer certaines des bonnes pratiques décrites dans la section ci-dessous.
Recommandations pour ne pas dépasser les limites d'utilisation de l'API
Lorsque vous utilisez l'API Google Play EMM, vous pouvez appliquer certaines bonnes pratiques pour distribuer les requêtes et réduire les risques de dépassement des limites d'utilisation.
Afficher les heures de début et les intervalles de manière aléatoire
Des activités comme la synchronisation ou l'enregistrement d'appareils en même temps peuvent entraîner une augmentation significative du volume de requêtes. Au lieu d'effectuer ces activités à intervalles réguliers, vous pouvez répartir la charge de vos requêtes de manière aléatoire sur ces intervalles. Par exemple, plutôt que de synchroniser chaque appareil toutes les 24 heures, vous pouvez synchroniser chaque appareil sur une période choisie de manière aléatoire entre 23 et 25 heures. Cela permet de répartir le nombre de demandes.
De même, si vous exécutez une tâche quotidienne qui effectue une série d'appels d'API rapidement, envisagez de démarrer la tâche à une heure aléatoire chaque jour pour éviter d'envoyer un grand nombre de requêtes en même temps.
Utiliser un intervalle exponentiel entre les tentatives pour relancer les requêtes
Si vous exécutez des tâches composées de nombreux appels d'API, utilisez un intervalle exponentiel entre les tentatives pour atteindre le quota. L'intervalle exponentiel entre les tentatives est un algorithme qui renouvelle les requêtes de manière exponentielle. Voici un exemple de flux d'implémentation d'un intervalle exponentiel entre les tentatives simple:
- Envoyez une requête à l'API EMM Google Play.
- Recevez une réponse
HTTP 429. - Patientez 2 secondes +
random_time, puis relancez la requête. - Recevez une réponse
HTTP 429. - Patientez quatre secondes +
random_time, puis relancez la requête. - Recevez une réponse
HTTP 429. - Patientez huit secondes +
random_time, puis relancez la requête.
La valeur random_time est généralement un nombre aléatoire compris entre -0,5 * temps d'attente et +0,5 * temps d'attente. Redéfinissez le random_time à chaque nouvelle tentative. Les appels d'API nécessaires pour effectuer des actions destinées aux utilisateurs peuvent être déclenchés plus fréquemment (0, 5 s, 1 s et 2 s, par exemple).
Processus par lot de limitation du débit
Chaque fois qu'un processus par lot atteint le quota, la latence des actions de l'utilisateur qui appellent l'API augmente. Dans de telles situations, des stratégies telles qu'un intervalle exponentiel entre les tentatives peuvent ne pas être suffisamment efficaces pour maintenir une faible latence des actions de l'utilisateur.
Pour éviter d'atteindre les limites d'utilisation de l'API à plusieurs reprises et d'augmenter la latence pour les actions des utilisateurs, envisagez d'utiliser un limiteur de débit pour vos processus par lot (consultez RateLimit de Google). Avec un limiteur de débit, vous pouvez ajuster le débit de vos requêtes API afin de toujours rester en dessous des limites d'utilisation.
Par exemple, lancez un processus par lot avec une limite de débit par défaut de 50 RPS. Tant que l'API ne renvoie pas d'erreur, augmentez progressivement la limite de débit (1% toutes les minutes). Chaque fois que vous atteignez le quota, vous pouvez réduire votre taux de requêtes de 20%. Cette approche adaptative se traduit par un taux de requêtes plus optimal tout en réduisant la latence pour les actions des utilisateurs.