Jede Anfrage an My Geocode durchläuft dieselbe Serving-Infrastruktur, bevor eine Antwort zurückkommt, unabhängig davon, welchen Endpunkt sie trifft oder für welchen Kompatibilitäts-Host sie formatiert ist. Wir haben kürzlich ein Upgrade dieser gemeinsamen Infrastruktur abgeschlossen, und das Ergebnis sind durchweg schnellere Antwortzeiten.
Es handelt sich um eine plattformweite Änderung, nicht um etwas, das einen einzelnen Endpunkt betrifft. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete und /v1/postcode laufen alle auf demselben aktualisierten Stack, ebenso alle siebzehn Kompatibilitäts-Hosts. An Anfrageparametern, Antwortfeldern, Authentifizierungsmethoden oder Preisen hat sich dabei nichts geändert. Das Upgrade findet vollständig hinter den Kulissen statt und ist nur daran zu erkennen, wie schnell eine Antwort zurückkommt.
Bei den meisten Integrationen wird diese Art von Verbesserung eher gespürt als genau gemessen, als allgemeiner Eindruck, dass Aufrufe etwas schneller zurückkommen als zuvor. Bei Integrationen mit nennenswertem Volumen, insbesondere Batch-Jobs, die viele Einträge nacheinander verarbeiten, oder allem mit Traffic im Stil einer Autovervollständigung, der beim Tippen wiederholt ausgelöst wird, summiert sich der Effekt über viele Anfragen und wird direkter spürbar. Ein Autovervollständigungsfeld, das bei jedem Tastendruck eines Suchbegriffs mit acht Zeichen eine Anfrage sendet, macht acht Aufrufe in der Zeit, die das Tippen dauert, und schon eine kleine Einsparung bei jedem einzelnen verändert, wie sich die gesamte Interaktion anfühlt, auf eine Weise, die eine einzelne, alleinstehende Abfrage gar nicht zeigen würde.
Infrastrukturarbeit wie diese verstehen wir als dauerhafte Verantwortung und nicht als einmaliges Projekt. Eine Geokodierungs-API, auf der Menschen echte Produkte aufbauen, muss auch bei wachsender Nutzung zuverlässig schnell bleiben, nicht nur am Tag des Starts. Das bedeutet, den Serving-Stack regelmäßig zu überprüfen, statt ihn auf unbestimmte Zeit unverändert zu lassen. Dieses Upgrade ist ein Schritt in diesem fortlaufenden Prozess, kein endgültiges Ziel.
Da jeder Endpunkt und jeder Kompatibilitäts-Host über denselben gemeinsamen Stack läuft, muss ein Upgrade wie dieses nur einmal erfolgen, um allen zugutezukommen, statt Endpunkt für Endpunkt oder Host für Host wiederholt zu werden. Dieses gemeinsame Design ist auch der Grund, warum eine Änderung hier nie Anfrageformate, Antwortfelder oder die Kontingent-Logik berührt: Diese liegen auf einer völlig anderen Ebene.
An der Kontingent- und Abrechnungslogik ändert sich dadurch nichts. Jede Antwort enthält weiterhin den vollständigen Satz an Kontingent-Headern, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit und X-Quota-Reset, und die kostenlosen Kontingente, der Preis für Prepaid-Guthaben und der Preis des Unlimited-Pakets bleiben unverändert.
Auf demselben gemeinsamen Stack läuft auch jeder Kompatibilitäts-Host. Ein Aufruf im TomTom-Format und ein nativer Aufruf an /v1/forward profitieren daher gleichermaßen, und die Verbesserung muss weder pro Host angefordert noch für eine bestimmte Integration separat vereinbart werden.
Wenn Ihre Integration empfindlich auf Antwortzeiten reagiert, sei es, weil sie direkt für Nutzer sichtbar ist oder weil sie große Mengen an Batch-Anfragen verarbeitet, sollten Sie einen Unterschied bemerken, ohne auf Ihrer Seite etwas ändern zu müssen. Die vollständige Dokumentation aller Endpunkte bleibt genau so, wie sie war, und ist unter /docs/ verfügbar.