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.
Offene Zeitzonendaten sollten keine Premium-Funktion sein
Die IANA-Zeitzonendatenbank ist öffentlich. Sie wird seit Jahrzehnten offen gepflegt und erfasst jede Änderung von Offsets, jede Sommerzeitregel und jede Neuziehung von Grenzen, die Regierungen vornehmen. Nahezu jede ernsthafte Zeitzonenabfrage im Internet, unsere eingeschlossen, baut auf genau diesem öffentlichen Datensatz auf. Wenn eine API also einen gesonderten Premium-Preis speziell für Zeitzonenabfragen verlangt, zusätzlich zu dem, was sie bereits für die Geokodierung berechnet, lohnt sich die Frage, wofür dieser Aufpreis eigentlich bezahlt wird.
Manchmal ist die Antwort legitim: Entwicklungszeit, die aufgewendet wird, um die Zuordnung zwischen Koordinaten und Zeitzonengrenzen genau zu halten, wenn sich diese Grenzen verschieben, und Infrastruktur, um Abfragen in großem Umfang zu bedienen. Das ist echte Arbeit, und sie kostet etwas. Weniger legitim ist es, Zeitzonendaten als eigene Produktlinie mit eigener Preisstufe zu behandeln, deutlich über den Grenzkosten einer Abfrage, weil sie sich in einen Workflow bündeln lassen, den ein Kunde ohnehin braucht, und für den er sich seltener separat nach Alternativen umsieht.
Wir lagern Zeitzonen nicht als Premium-Zusatz aus. Es ist ein Endpunkt unter mehreren, zum selben Preis wie jeder andere Endpunkt: abgedeckt durch das kostenlose Tageskontingent und darüber hinaus zu denselben 0,0001 € pro Anfrage abgerechnet wie alles andere oder im selben Unlimited-Schlüssel für 50 € enthalten. Es gibt keine gesonderte Zeitzonenstufe und keinen Aufschlag für die Frage, wie spät es an einem bestimmten Koordinatenpaar ist.
Zeitzonenabfragen sind wichtiger, als ihr unscheinbarer Name vermuten lässt. Terminplanungssysteme, Logging-Pipelines, Buchungsplattformen und alles, was einem Nutzer die korrekte Ortszeit anzeigen muss, hängen davon ab, dass dies stimmt. Geht es schief, landet eine Besprechungseinladung eine Stunde daneben, ein Log-Zeitstempel führt eine Untersuchung in die Irre oder ein Lieferfenster verspricht die falsche Ortszeit. Genau diese Art von Abfrage sollte günstig und langweilig sein und nicht ein Posten, der als überraschender Sprung auf einer Rechnung auftaucht.
Ein Grund, warum Zeitzonenabfragen anderswo als Premium-Funktion behandelt werden, ist, dass Sommerzeitumstellungen und Grenzänderungen die zugrunde liegenden Daten komplizierter erscheinen lassen als statische Ländercodes. Es sind tatsächlich knifflig zu pflegende Daten. Aber knifflig in der Pflege ist nicht dasselbe wie teuer in der Bereitstellung pro Anfrage, und die Preise sollten sich nach Letzterem richten, nicht nach der Komplexität des Ersteren.
Ein Aufpreis für Zeitzonendaten schafft auch auf der Ebene des API-Designs einen schlechten Anreiz: Anbieter wollen sie nicht mehr direkt bereitstellen, sondern lieber in größere, teurere Pakete verpacken, nach dem Motto, dass sich eine Funktion, deren Preis niemand einzeln vergleichen kann, leichter mit Aufschlag versehen lässt. Wir glauben, dass der umgekehrte Ansatz mehr Vertrauen schafft. Machen Sie den Endpunkt schlicht, bepreisen Sie ihn wie alles andere und lassen Sie Entwickler ihn genau so oft nutzen, wie ihre Anwendung es braucht, ohne im Kopf nachrechnen zu müssen, ob diese bestimmte Abfrage zu den teuren gehört.