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.
Man ist versucht, einen Batch-Endpunkt als Gelegenheit für einen Mengenrabatt zu sehen, derselbe Reflex, durch den sich eine Großpackung pro Stück günstiger anfühlt als der Kauf einzelner Teile. Dieser Reflex gilt für API-Anfragen aber nicht so, wie er für physische Waren gilt. Ein Batch von tausend Adressabfragen erfordert dieselben tausend einzelnen Abfragen, ob sie nun über eine Verbindung oder über tausend separate Verbindungen eintreffen. In der Tatsache, dass sie zusammen ankamen, verbirgt sich kein Skaleneffekt, denn der teure Teil, das Auflösen jeder einzelnen Abfrage, ist in beiden Fällen identisch.
Wir berechnen Batch- und Massenanfragen pro Element genau wie einzelne Anfragen. Ein Batch-Aufruf mit tausend Elementen zählt als tausend Anfragen gegen Ihr kostenloses Kontingent oder Ihr Prepaid-Guthaben, zum selben Preis von 0,0001 € pro Anfrage, als würden Sie den Endpunkt tausendmal einzeln aufrufen, oder wird auf dieselbe Weise durch einen Unlimited-Schlüssel abgedeckt. Es gibt keinen separaten, günstigeren Batch-Tarif, weil es keine separate, geringere Menge an zugrunde liegender Arbeit gibt.
Manche Anbieter gewähren einen Mengenrabatt, und der Reiz für den Kunden liegt auf der Hand: mehr senden, weniger pro Einheit zahlen. Die Begründung für diesen Rabatt sollte man eher hinterfragen, als ihn einfach zu begrüßen. Wenn die Grenzkosten für die Bearbeitung einer Abfrage tatsächlich nahezu konstant sind, wie bei den meisten Geokodierungs-, IP- und Zeitzonenabfragen, gibt ein Mengenrabatt keinen echten Effizienzgewinn weiter. Er ist eine Preisentscheidung, kleineren Kunden mehr zu berechnen, um einen niedrigeren Tarif für größere zu subventionieren, verpackt als Belohnung für Volumen statt als das, was er tatsächlich ist: eine Quersubventionierung.
Pauschale Preise pro Element vermeiden diese Quersubventionierung vollständig. Ein Kunde, der hundert Anfragen pro Tag sendet, und einer, der hunderttausend sendet, zahlen genau denselben Preis pro Anfrage, sobald beide das kostenlose Kontingent überschritten haben. Keiner subventioniert die Nutzung des anderen. Das hält auch das kostenlose Kontingent selbst fair: Ein Batch-Aufruf verbraucht dasselbe tägliche Kontingent von 2.500 Anfragen im selben Verhältnis von einer Anfrage pro Element, sodass Batching nicht dazu genutzt werden kann, die kostenlose Nutzung stillschweigend weiter zu strecken, als es eine entsprechende Zahl einzelner Aufrufe täte.
Uns ist bewusst, dass Batching aus Gründen, die nichts mit dem Preis zu tun haben, wirklich nützlich ist: weniger Round Trips, weniger Verbindungsaufwand, einfacherer Code, um eine große, bekannte Menge von Abfragen auf einmal zu verarbeiten. Das sind echte technische Vorteile, und es lohnt sich, Batch-Endpunkte allein deswegen zu nutzen. Was Batching nicht werden sollte, ist ein Mechanismus, der dieselbe Gesamtarbeit auf einer Rechnung günstiger aussehen lässt, als sie tatsächlich ist. Tausend Abfragen kosten, was tausend Abfragen kosten, und der Preis sollte das klar sagen, unabhängig davon, wie sie in Anfragen verpackt wurden.