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.
Checkout-Formulare scheitern an Adressfeldern häufiger als an jedem anderen Feld, meist weil ein Kunde einen Straßennamen falsch eintippt oder eine Wohnungsnummer weglässt. Echte Adressen schon während der Eingabe vorzuschlagen, behebt das meiste davon, bevor daraus eine fehlgeschlagene Zustellung wird.
Der Endpunkt /v1/autocomplete nimmt einen Teiltext und eine Obergrenze dafür entgegen, wie viele Vorschläge zurückgegeben werden sollen. Rufen Sie ihn auf, während der Kunde tippt, sobald er einige Zeichen eingegeben hat.
GET /v1/autocomplete?q=221B Baker&limit=5{
"status": "ok",
"query": "221B Baker",
"suggestions": [
{"text": "221B Baker Street, London, UK", "place_id": "abc123"},
{"text": "221B Baker Avenue, Springfield", "place_id": "abc124"}
]
}Ein Vorschlag besteht aus einer kurzen Bezeichnung und einer place_id, nicht aus einem vollständigen Adressdatensatz. Sobald der Kunde einen Vorschlag auswählt, lösen Sie ihn in eine vollständige Adresse mit Bestandteilen und Koordinaten auf, indem Sie den Vorschlagstext an /v1/forward übergeben. Dieser zweite Aufruf füllt die Felder für Straße, Stadt, Region und Postleitzahl in Ihrem Formular aus.
GET /v1/forward?q=221B Baker Street, London, UK&limit=1Erst in dieser zweiten Anfrage erscheint tatsächlich das Objekt components, da /v1/autocomplete immer nur eine Textbezeichnung und eine place_id liefert, nie eine Aufschlüsselung in Straße, Stadt und Postleitzahl. Diesen Schritt zu überspringen und den Vorschlagstext selbst zu parsen, ist fehleranfälliger, als es aussieht, da die Formatierung von Land zu Land unterschiedlich ist.
Bei jedem Tastendruck eine Anfrage abzusetzen, summiert sich auf einer stark besuchten Checkout-Seite schnell. Verzögern Sie das Feld per Debounce, sodass eine Anfrage erst ausgelöst wird, wenn der Kunde kurz mit dem Tippen innehält, und lassen Sie Anfragen für alles unter drei oder vier Zeichen weg, wo Vorschläge ohnehin nicht hilfreich sind. Jeder Autovervollständigungsaufruf und jeder anschließende Geokodierungsaufruf zählt als eine Anfrage gegen Ihr tägliches Kontingent, sodass ein Feld mit Debounce selbst in einem viel besuchten Shop deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag bleiben kann, die in jedem Schlüssel enthalten sind.
Ein leeres Array suggestions ist eine normale Antwort, kein Fehler. Lassen Sie den Kunden weitertippen und greifen Sie auf ein einfaches Textfeld für die Adresse zurück, wenn nach einigen Zeichen nichts Brauchbares zurückkommt, statt das Absenden des Formulars davon abhängig zu machen, dass ein Vorschlag ausgewählt wurde.
Einen angeklickten Vorschlag als fertige, geprüfte Adresse zu behandeln, ist eine verbreitete Abkürzung, die später Probleme verursacht. Ein Kunde kann einen Vorschlag auswählen und das Feld danach weiter bearbeiten, etwa eine Hausnummer ändern oder eine Wohnungsnummer ergänzen, die der ursprüngliche Vorschlag nie enthielt. Lösen Sie den endgültigen Text des Feldes beim Absenden immer über /v1/forward auf, nicht nur in dem Moment, in dem ein Vorschlag angeklickt wurde, damit die gespeicherte Adresse dem entspricht, was tatsächlich im Feld gelandet ist.
Wenn Ihr Checkout-Formular die Postleitzahl zusätzlich separat erfasst, ist ein kurzer Aufruf von /v1/postcode, sobald die Straßenadresse aufgelöst ist, eine günstige Möglichkeit, eine Postleitzahl zu erkennen, die nicht zum Rest der Adresse passt, bevor beide zusammen abgeschickt werden und später zu einer Unstimmigkeit beim Versand führen.
Autovervollständigung ersetzt keine Validierung, sie verringert lediglich die Wahrscheinlichkeit, dass eine fehlerhafte Adresse überhaupt in Ihr Bestellsystem gelangt. Die vollständige Parameterliste finden Sie in der Dokumentation zur Adress-Autovervollständigung, bevor Sie sie in Ihren Checkout-Ablauf einbinden.