Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum wir Sammelanfragen pro Element zählen, nicht pro Aufruf
Ein Batch-Endpunkt, der tausend Adressen in einem Aufruf annimmt und nur als eine einzige Anfrage gegen Ihr Kontingent zählt, sieht auf einer Preisseite großzügig aus. Er ist nicht großzügig. Er ist ein Rundungsfehler, der nur darauf wartet, zu einem Kapazitätsproblem zu werden, denn die tatsächliche Arbeit hinter diesem Aufruf, tausend einzelne Abfragen, ist nicht geschrumpft, nur weil sie in einem Umschlag ankam.
Wir zählen Massen- und Batch-Anfragen so, wie wir alles andere zählen: ein Element, eine Anfrage. Wenn Sie tausend Adressen in einem einzigen Batch-Aufruf senden, sind das tausend Anfragen gegen Ihr kostenloses Kontingent oder Ihr Prepaid-Guthaben, genau so, als hätten Sie den Endpunkt tausendmal einzeln aufgerufen. Der Komfort des Batchings, also weniger Round Trips und weniger Verbindungsaufwand, ist real und lohnenswert. Die Kosten der Abfragen selbst ändern sich nicht, weil Sie sie gemeinsam angefordert haben.
Batch-Aufrufe künstlich billig zu machen, erzeugt eine merkwürdige Verzerrung. Es belohnt, die eigene Integration nur zum Sparen auf große Batch-Aufrufe umzubauen, statt weil Batching wirklich zum Arbeitsablauf passt. Außerdem wird die tatsächliche Kapazitätsplanung eines Anbieters von außen schwerer nachvollziehbar, denn eine „Anfrage“ ist dann keine einheitliche Arbeitseinheit mehr. Wer Anbieter nach Anfragen pro Tag vergleicht, kann nicht fair vergleichen, wenn die Anfrage des einen Anbieters heimlich tausend Abfragen enthalten kann und die des anderen nicht.
Die Zählung pro Element hält auch unsere Kontingent-Header aussagekräftig. Jede Antwort enthält, wie viel Sie verbraucht haben und wie viel übrig ist, und diese Zahl bedeutet nur dann etwas, wenn eine Anfrage eine Anfrage ist, egal wie sie aufgebaut war. Würde ein Batch mit tausend Elementen stillschweigend nur eine Einheit kosten, sagten diese Header fast nichts über Ihren tatsächlichen Verbrauch aus, und die wahre Zahl würden Sie erst erfahren, wenn ein deutlich größeres, nicht gebündeltes Nutzungsmuster an ein Limit stößt, mit dem Sie nicht gerechnet haben.
Es gibt auch ein Fairness-Argument. Ein Kunde, der einzelne Aufrufe sendet, und ein Kunde, der Batches sendet, verlangen von uns insgesamt dieselbe Arbeit zum insgesamt selben Preis. Würden wir dem Batch-Kunden pro Abfrage weniger berechnen, nur weil die Anfragen gebündelt sind, würde der Kunde mit Einzelaufrufen faktisch Infrastruktur subventionieren, die gar nicht er belastet. Beiden pro Abfrage denselben Preis zu berechnen, bindet den Preis an die Arbeit und nicht daran, wie die Arbeit verpackt wurde.
Nichts davon macht Batching sinnlos. Es ist nach wie vor der richtige Weg, eine große, bekannte Menge von Abfragen in einem einzigen Roundtrip zu senden, und wir unterstützen es, weil weniger Verbindungen und weniger Overhead auf Ihrer Seite ein echter Effizienzgewinn sind. Was Batching auf keiner Seite der Anfrage tun sollte, ist, die tatsächlichen Kosten der Abfragen zu verändern. Tausend Abfragen sind tausend Abfragen, ob sie einzeln über einen Nachmittag verteilt eintreffen oder alle auf einmal in einem einzigen Aufruf.