Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Einen Fallback einrichten, wenn eine Abfrage kein Ergebnis liefert
Eine Anfrage, die erfolgreich zurückkommt, aber kein brauchbares Ergebnis enthält, wird leicht falsch behandelt, denn auf HTTP-Ebene sieht sie nicht wie ein Fehler aus, sie enthält nur nicht die Antwort, auf die Sie gehofft hatten.
Wie ein leeres Ergebnis aussieht
Eine Geokodierungssuche (Adresse zu Koordinaten) nach etwas zu Vagem oder völlig Erfundenem liefert den Status 200 mit einem leeren Ergebnis-Array, keinen Fehlercode.
GET /v1/forward?q=xyzzy nonexistent place&limit=1{
"status": "ok",
"query": "xyzzy nonexistent place",
"results": []
}Eine IP-Abfrage für eine Adresse in einem nicht zugewiesenen oder privaten Bereich liefert found: false statt eines Fehlers, zusammen mit allen Feldern, die sie trotzdem befüllen kann.
{
"status": "ok",
"ip": "10.0.0.5",
"version": 4,
"found": false
}Einen expliziten Ausweichpfad aufbauen
Prüfen Sie auf ein leeres Ergebnis-Array oder found: false als eigenen Zweig in Ihrem Code, getrennt sowohl vom Erfolgspfad als auch von der Fehlerbehandlung für 4xx- und 5xx-Antworten. Entscheiden Sie bewusst, was danach geschieht: Bitten Sie den Nutzer, seine Eingabe zu präzisieren, weichen Sie auf eine breitere Suche mit höherem limit aus, oder zeigen Sie eine klare Meldung „Standort nicht gefunden“ statt einer leeren Fläche oder eines irreführenden Standardwerts.
Häufige Ursachen, die Sie zuerst prüfen sollten
Ein tatsächlich nicht existierender Ort ist eine Ursache, aber auch eine schlecht formatierte Eingabe, ein Tippfehler oder eine Abfrage, die unerwartet Sprachen oder Schriften mischt, kann für eine Adresse, die tatsächlich existiert, ein leeres Ergebnis liefern. Bevor Sie annehmen, dass der Ort selbst nicht existiert, prüfen Sie, ob eine Normalisierung der Eingabe oder ein Versuch mit gesetztem countries-Parameter das Problem löst.
Leere Ergebnisse separat protokollieren
Verfolgen Sie, wie oft Ihre Integration auf den Pfad für leere Ergebnisse trifft, getrennt von Ihrer Fehlerquote. Eine steigende Quote leerer Ergebnisse deutet oft auf ein Datenqualitätsproblem weiter vorne in der Kette hin, bei der Erfassung oder Formatierung der Adressen, und nicht auf ein Problem mit der Abfrage selbst.
Kosten einer Abfrage ohne Ergebnis
Ein leeres Ergebnis kostet trotzdem eine Anfrage, genau wie ein erfolgreicher Treffer, da die Abfrage in beiden Fällen durchgeführt wurde. Einen gesonderten ermäßigten Tarif für eine Abfrage, die leer zurückkommt, gibt es nicht.
Wenn Sie ein leeres Ergebnis als eigenes, bewusstes Resultat behandeln statt als nachträglich an die Fehlerbehandlung angehängten Gedanken, wird eine Integration spürbar robuster. Die Seite zu Fehlern behandelt echte Fehlerantworten, während leere Ergebnisse zusammen mit der normalen Antwortstruktur jedes Endpunkts dokumentiert sind, etwa in der Dokumentation zur Geokodierung.