Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Polling für einen großen Batch-Job ohne Webhook einrichten
Manche APIs geben für einen großen Batch eine Job-ID zurück und erwarten, dass Sie abfragen oder auf einen Webhook warten, während er im Hintergrund verarbeitet wird. Diese API funktioniert nicht so. Jede Bulk-Anfrage, ob groß oder klein, wird synchron im selben Aufruf beantwortet, und das ändert, wie Sie über die Ausführung eines sehr großen Jobs nachdenken sollten.
Blöcke statt Warteschlange
Statt ein riesiges Array zu übermitteln und zu warten, teilen Sie einen großen Job in Blöcke fester Größe auf, jeweils einige hundert bis einige tausend Elemente, und senden Sie sie als Folge gewöhnlicher Bulk-POST-Anfragen. Da jeder Aufruf seine Ergebnisse sofort zurückgibt, gibt es keinen Job-Status abzufragen, nur den nächsten Block zu senden.
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]Was „Polling“ hier tatsächlich bedeutet
Was in diesem Aufbau dem Polling am nächsten kommt, ist das Prüfen Ihrer eigenen Kontingent-Header zwischen den Blöcken statt des Prüfens eines Job-Status. Lesen Sie nach jedem abgeschlossenen Block X-Quota-Free-Remaining und X-Credits-Remaining, und pausieren oder stoppen Sie den Job, wenn Sie kurz davor sind, Ihr kostenloses Tageskontingent zu überschreiten, ohne genug Prepaid-Guthaben zum Weitermachen zu haben.
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50Einen einfachen Runner bauen
Ein kleines Skript, das über die Blöcke iteriert, jeden sendet, die Header der Antwort prüft und je nach Befund weitermacht oder pausiert, ist alles, was ein großer Batch-Job hier braucht. Es gibt keinen separaten Endpunkt für den Job-Status, da der gerade gesendete Block bereits alles enthält, was Sie angefragt haben.
Fortsetzen nach einer Pause
Merken Sie sich, bis zu welchem Blockindex Sie bisher erfolgreich verarbeitet haben, damit eine Pause für einen Kontingent-Reset oder eine Guthabenaufladung genau dort fortgesetzt werden kann, wo sie aufgehört hat, statt frühere Blöcke erneut zu verarbeiten und Anfragen doppelt zu verbrauchen.
Was es kostet
Die Kosten sind so oder so dieselben: eine Anfrage pro Element über den gesamten Job. Der Ansatz mit Blöcken ändert nur, wie Sie den Job verwalten, nicht, wie viele Anfragen er insgesamt verbraucht.
Einen großen Job als Folge gewöhnlicher synchroner Blöcke zu behandeln, statt nach einem asynchronen Job-System zu suchen, das es hier nicht gibt, hält das Ganze einfach. Die Dokumentation zu Ratenlimits behandelt die Kontingent-Header, auf denen dieses Muster beruht.