L'API EMM Google Play a une limite par défaut de 60 000 requêtes par minute pour chaque fournisseur EMM.
Si vous dépassez le quota, l'API Google Play EMM 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, envisagez d'appliquer certaines des bonnes pratiques décrites dans la section ci-dessous.
Recommandations pour rester en dessous des 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 le risque de dépasser les limites d'utilisation.
Randomiser les heures de début et les intervalles
Des activités telles que la synchronisation ou l'enregistrement d'appareils en même temps sont susceptibles d'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 en randomisant ces intervalles. Par exemple, au lieu de synchroniser chaque appareil toutes les 24 heures, vous pouvez le faire à un moment choisi de manière aléatoire entre 23 et 25 heures. Cela permet de répartir le nombre de requêtes.
De même, si vous exécutez une tâche quotidienne qui effectue de nombreux appels d'API en succession rapide, envisagez de la démarrer à une heure aléatoire chaque jour pour éviter d'envoyer un grand nombre de requêtes à tous vos clients professionnels en même temps.
Utiliser un intervalle exponentiel entre les tentatives de requête
Si vous exécutez des tâches composées de nombreux appels d'API, utilisez une stratégie d'intervalle exponentiel entre les tentatives lorsque vous atteignez le quota. L'intervalle exponentiel entre les tentatives est un algorithme qui relance les requêtes de manière exponentielle. Voici un exemple de flux d'implémentation d'un intervalle exponentiel simple entre les tentatives:
- Envoyez une requête à l'API Google Play EMM.
- Vous devriez recevoir une réponse
HTTP 429. - Patientez deux secondes +
random_time, puis relancez la requête. - Vous devriez recevoir une réponse
HTTP 429. - Vous patientez 4 secondes +
random_time, puis vous relancez la requête. - Vous devriez recevoir une réponse
HTTP 429. - Vous patientez 8 secondes +
random_time, puis vous relancez la requête.
random_time est généralement un nombre aléatoire compris entre -0,5 * durée d'attente et +0,5 * durée d'attente. Redéfinissez un random_time chaque fois que vous réessayez votre requête. Les appels d'API requis pour effectuer des actions visibles par l'utilisateur peuvent être réessayés à une fréquence plus élevée (0, 5 s, 1 s et 2 s, par exemple).
Limiter le débit des traitements par lot
Chaque fois qu'un processus par lot atteint le quota, la latence des actions utilisateur qui appellent l'API augmente. Dans de telles situations, des stratégies telles que le backoff exponentiel peuvent ne pas être suffisamment efficaces pour maintenir une faible latence pour les actions des utilisateurs.
Pour éviter d'atteindre les limites d'utilisation de l'API de manière répétée et d'augmenter la latence pour les actions visibles par les utilisateurs, envisagez d'utiliser un limiteur de fréquence pour vos processus par lot (voir RateLimiter de Google). Avec un limiteur de débit, vous pouvez ajuster le débit de vos requêtes API afin de rester constamment en dessous des limites d'utilisation.
Par exemple, démarrez un traitement par lot avec une limite de débit par défaut de 50 RPS. Tant que l'API ne renvoie pas d'erreur, augmentez lentement la limite de débit (1% toutes les minutes). Chaque fois que vous atteignez le quota, réduisez 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.