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 das Produkt so gebaut haben, wie wir es selbst kaufen wollen würden
Wir bauen und betreiben eine Geokodierungs-API. Das ist das ganze Unternehmen. Jede Entscheidung, die in den übrigen Beiträgen beschrieben ist, Preise pro Anfrage statt pro Nutzerplatz, eine kostenlose Stufe ohne Schlüssel statt einer ablaufenden Testphase, Kompatibilitäts-Hosts statt eines proprietären Formats, Kontingent-Header in jeder Antwort statt eines verzögerten Dashboards, geht auf denselben einfachen Test zurück, den wir beim Bauen immer wieder angewendet haben: Würde uns das ärgern, wenn wir der Kunde auf der anderen Seite wären?
Die meisten schlechten Gewohnheiten, über die wir in dieser Sammlung geschrieben haben, fallen bei diesem Test sofort durch, sobald man sich tatsächlich vorstellt, selbst dafür zu bezahlen. Niemand möchte ein Ratenlimit durch eine fehlgeschlagene Anfrage im Produktivbetrieb entdecken. Niemand möchte einen „unbegrenzten“ Tarif, an dem sich dann doch eine Fair-Use-Richtlinie findet. Niemand möchte eine Migration, die ein Quartal dauert, weil das SDK des bisherigen Anbieters seine Strukturen jahrelang über eine Codebasis verstreut hat. Das sind keine abwegigen Beschwerden. Es sind Dinge, die fast jeder Entwickler schon von der anderen Seite einer API-Beziehung erlebt hat, und genau deshalb glauben wir nicht, dass es Kundenforschung braucht, um sie als vermeidenswerte Probleme zu erkennen.
Bei den Preisen ließ sich das am deutlichsten anwenden. 2.500 kostenlose Anfragen pro Tag von jeder Adresse, ganz ohne Schlüssel. Wenn Sie mehr brauchen, registrieren Sie sich mit einer E-Mail-Adresse und laden entweder Prepaid-Guthaben zu 0,0001 € pro Anfrage auf oder nehmen einen Unlimited-Schlüssel für 50 € pro Monat. Jeder Endpunkt und jeder Drop-in-Host kostet gleich viel. Dazu sind wir nicht durch eine Preisoptimierung gekommen, die den Umsatz pro Kunde maximieren sollte. Wir sind dazu gekommen, indem wir uns gefragt haben, wie ein fairer, ehrlicher Preis für genau dieses Produkt für jemanden aussehen würde, der sich schon über undurchsichtige Stufen, Überschreitungsgebühren und Enterprise-Verkaufsgespräche geärgert hat, denn jeder von uns war irgendwann einmal dieser Jemand.
Derselbe Test gilt für kleinere Entscheidungen, die nie auf einer Preisseite auftauchen: einen Schlüssel ohne Aufpreis über einen Header, ein Bearer-Token, Basic Auth oder einen Query-Parameter zu akzeptieren, weil das Erzwingen eines bestimmten Musters unnötige Reibung für alle bedeutet, deren vorhandener Code es bereits anders macht. Fehlercodes und Ratenlimits klar zu veröffentlichen, weil das Rätseln über einen undokumentierten Fehler die Zeit aller verschwendet. Keine dieser Entscheidungen ist spektakulär. Sie sind die Summe davon, das Ärgerliche wiederholt nicht zu tun, in jedem Teil des Produkts.
Wir behaupten nicht, dass dadurch jeder Teil des Produkts fertig oder perfekt ist. Wir sagen genau, welche Endpunkte wir als voll funktionsfähig betrachten und welche, etwa Geokodierung, Reverse-Geokodierung und Autovervollständigung, wir vorsichtig beschreiben, statt sie zu überverkaufen, denn Überverkaufen ist eine eigene Form desselben Versagens: einem Kunden zu sagen, was er hören möchte, statt was tatsächlich stimmt. Das Produkt zu bauen, das wir selbst kaufen wollen würden, heißt, es ehrlich zu bauen, auch was seine aktuellen Grenzen angeht, und nicht nur die Teile zu bauen, auf die man leicht stolz sein kann. Das ist der Maßstab, den wir uns gesetzt haben, und an ihm wollen wir uns weiterhin messen lassen.