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 lieber mit einem Fehler antworten als mit einer falschen Vermutung
Eine API, die immer etwas zurückgibt, selbst bei einer Anfrage, die sie nicht gut beantworten kann, wirkt auf den ersten Blick leistungsfähiger als eine, die manchmal stattdessen einen klaren Fehler zurückgibt. Der Eindruck täuscht. Eine Antwort, die eine Lösung errät, statt Unsicherheit zuzugeben, ist nicht nützlicher. Sie ist gefährlicher, gerade weil sie genau wie eine selbstsichere, korrekte Antwort aussieht und dem Aufrufer kein Signal gibt, weiter zu prüfen, bevor er danach handelt.
Wir geben lieber einen klaren Fehler zurück oder eine Antwort, die eindeutig auf einen Treffer mit geringer Sicherheit oder einen Teiltreffer hinweist, als stillschweigend eine bestmögliche Vermutung zu liefern, die als normale Antwort verkleidet ist. Das ist vor allem bei der Geokodierung (Adresse zu Koordinaten), der Reverse-Geokodierung und der Autovervollständigung wichtig, also genau bei den Endpunkten, an denen eine unvollständige oder mehrdeutige Adresse ein System dazu verleiten kann, den nächstliegenden plausiblen Treffer zurückzugeben, statt einzugestehen, dass sich die Eingabe nicht sauber auflösen ließ. Ein nächstliegender plausibler Treffer, der als normales Ergebnis präsentiert wird, ist der mit Abstand wahrscheinlichste Weg, auf dem fehlerhafte Standortdaten in einer Sendung, einer Prüfung des Liefergebiets oder einem Kundendatensatz landen, weil nichts an der Antwort darauf hinweist, dass irgendetwas unsicher war.
Das ist auch einer der Gründe, warum wir bewusst zurückhaltend damit sind, eine konkrete, überprüfte Genauigkeitszahl für Geokodierung und Autovervollständigung anzugeben, statt zu behaupten, dies seien vollständig fertige, bewährte Funktionen. Ein System, das selbstsicher genug ist, eine konkrete Genauigkeitszahl zu veröffentlichen, muss ebenso sicher sein, was bei den Eingaben passiert, die diese Zahl nicht abdeckt, und die ehrliche Antwort umfasst bei jedem Geokodierungssystem einen gewissen Anteil an Adressen, die als nicht aufgelöst oder mehrdeutig zurückkommen sollten, statt in eine Antwort gepresst zu werden.
Eine Fehlerantwort kostet im Moment etwas: Die aufrufende Anwendung muss einen Fehlerfall behandeln, statt immer ein sauberes Objekt zurückzubekommen, und das kann sich oberflächlich wie eine schlechtere Entwicklererfahrung anfühlen, denn eine Vermutung, die zufällig richtig ist, sieht genauso aus wie eine fehlerfreie Antwort, und eine Vermutung, die zufällig falsch ist, ebenfalls, bis es irgendwann weiter hinten jemandem auffällt. Genau das ist das Problem. Eine Vermutung und eine korrekte Antwort sind von außen nicht zu unterscheiden, und genau deshalb sollte ein System, das den Unterschied intern nicht erkennen kann, diese Lücke nicht überdecken, indem es eine Möglichkeit auswählt und als sicher präsentiert.
Wir finden, diese Präferenz, ein klarer Fehler statt einer selbstsicheren Vermutung, sollte eine Grunderwartung an jede Daten-API sein, nicht nur an unsere. Ein Aufrufer kann eine echte Fehlerbehandlung um ein System herum bauen, das ehrlich sagt, was es nicht weiß. Kein Aufrufer kann eine zuverlässige Fehlerbehandlung um ein System herum bauen, das immer antwortet, denn es gibt keine Möglichkeit, die Anfragen, die es tatsächlich richtig beantwortet hat, von denen zu unterscheiden, bei denen es stillschweigend geraten und zufällig falsch gelegen hat.