Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Mettre en place un suivi par interrogation pour un gros traitement par lots sans webhook
Certaines API renvoient un identifiant de tâche pour un gros lot et attendent que vous interrogiez régulièrement le serveur ou que vous attendiez un webhook pendant le traitement en arrière-plan. Celle-ci ne fonctionne pas ainsi. Chaque requête en masse, grande ou petite, reçoit sa réponse de manière synchrone dans le même appel, ce qui change la façon dont vous devez envisager l'exécution d'un très gros travail.
Découper plutôt que mettre en file d'attente
Plutôt que d'envoyer un énorme tableau et d'attendre, découpez un gros travail en blocs de taille fixe, de quelques centaines à quelques milliers d'éléments chacun, et envoyez-les sous forme d'une série de requêtes POST en masse ordinaires. Comme chaque appel renvoie immédiatement ses résultats, il n'y a aucun statut de tâche à interroger, seulement le bloc suivant à envoyer.
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]Ce que signifie vraiment « interroger » ici
Ce qui se rapproche le plus d'une interrogation dans ce schéma, c'est de vérifier vos propres en-têtes de quota entre les blocs plutôt qu'un statut de tâche. Lisez X-Quota-Free-Remaining et X-Credits-Remaining après chaque bloc terminé, et mettez le travail en pause, ou arrêtez-le, si vous êtes sur le point de dépasser votre quota gratuit quotidien sans assez de crédit prépayé pour continuer.
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50Construire un exécuteur simple
Un petit script qui parcourt les blocs, envoie chacun d'eux, vérifie les en-têtes de la réponse, puis continue ou se met en pause selon ce qu'il y lit : c'est tout ce dont un gros traitement par lots a besoin ici. Il n'y a pas d'endpoint distinct de statut de tâche à appeler, puisque le bloc que vous venez d'envoyer contient déjà tout ce que vous avez demandé.
Reprendre après une pause
Gardez la trace de l'index du dernier bloc traité avec succès, afin qu'une pause due à une réinitialisation du quota ou à une recharge de crédit puisse reprendre exactement là où elle s'était arrêtée, au lieu de retraiter les blocs précédents et de dépenser deux fois des requêtes.
Ce que cela coûte
Le coût est le même dans les deux cas : une requête par élément sur l'ensemble du travail. Le découpage en blocs change seulement la façon dont vous gérez le travail, pas le nombre total de requêtes qu'il utilise.
Traiter un gros travail comme une série de blocs synchrones ordinaires, plutôt que de chercher un système de tâches asynchrones qui n'existe pas ici, garde l'ensemble simple. La documentation sur les limites de débit couvre les en-têtes de quota sur lesquels repose ce schéma.