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.
Die meiste IP-Geolokalisierung im Web läuft über ein JavaScript-Tag, das vom Browser des Besuchers aus einen Drittanbieter aufruft. Das ist ein weiteres Skript, das geladen werden muss, eine weitere Anfrage, auf die der Browser warten muss, und eine weitere Sache, die unbemerkt fehlschlagen kann, wenn ein Besucher sie blockiert.
Der Endpunkt /v1/ip nimmt eine IP-Adresse entgegen und gibt direkt Standortdaten zurück. Wenn Sie ihn aus Ihrem eigenen Backend aufrufen und dabei die IP-Adresse verwenden, die Ihr Webserver bei der eingehenden Verbindung ohnehin sieht, läuft im Browser des Besuchers überhaupt kein Skript.
GET /v1/ip?ip=203.0.113.42{
"status": "ok",
"ip": "203.0.113.42",
"version": 4,
"found": true,
"country": "France",
"country_code": "FR",
"region": "Ile-de-France",
"city": "Paris",
"postcode": "75001",
"lat": 48.8566,
"lon": 2.3522,
"timezone": "Europe/Paris",
"asn": 12345,
"org": "Example Networks"
}Wenn Sie diesen Endpunkt ohne den Parameter ip aufrufen, wird die eigene Adresse des Aufrufers abgefragt. Das ist praktisch, wenn Ihr Backend die Anfrage im Auftrag des gerade verbundenen Besuchers stellt. Den Parameter ip explizit zu übergeben, ist das Richtige, wenn Sie die Adresse bereits protokolliert haben und sie später abfragen.
Land, Region und Stadt decken die meisten Anwendungsfälle der Personalisierung ab. Dank des Felds timezone brauchen Sie oft keine zweite Abfrage, nur um die Ortszeit dieses Besuchers zu kennen. Die Felder asn und org bezeichnen das Netz, zu dem die Adresse gehört, was für alles über einfache Personalisierung hinaus nützlich ist, etwa um Hosting-Anbieter oder Firmennetze zu erkennen.
Nicht jede Adresse lässt sich einem Standort zuordnen. Das Feld found ist false für einen Bereich, der reserviert, nicht vergeben oder schlicht nicht im Datensatz enthalten ist, und die Standortfelder fehlen in diesem Fall oder sind leer. Prüfen Sie found, bevor Sie country oder city auslesen, statt anzunehmen, dass eine erfolgreiche HTTP-Antwort immer einen verwertbaren Standort bedeutet, denn eine Anfrage für eine private oder reservierte Adresse liefert trotzdem ein 200 mit found auf false.
Diesen Endpunkt bei jedem einzelnen Seitenaufruf aufzurufen statt einmal pro Sitzung, ist der häufigste Grund, warum eine Website ihr Kontingent ohne echten Nutzen verbraucht. Die IP-Adresse eines Besuchers und damit sein ungefährer Standort ändert sich während desselben Besuchs normalerweise nicht von einer Seite zur nächsten. Fragen Sie sie einmal zu Beginn der Sitzung ab, speichern Sie das Ergebnis zur Sitzung und lesen Sie auf allen weiteren Seiten aus dieser gespeicherten Kopie, statt den Endpunkt erneut aufzurufen.
Jede IP-Abfrage ist eine Anfrage. Da sich der Standort eines Besuchers innerhalb einer Sitzung selten ändert, fragen Sie ihn einmal ab und speichern das Ergebnis für die Sitzung, statt ihn bei jedem Seitenaufruf abzufragen. So bleibt eine typische Website deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag, die in jedem Schlüssel enthalten oder von einer einzelnen Adresse auch ganz ohne Schlüssel verfügbar sind.
Derselbe Endpunkt und dieselbe Antwortstruktur funktionieren auch für IPv6-Adressen, ohne dass Sie Ihre Anfrage ändern müssen, und das Feld version in der Antwort zeigt Ihnen, welche Adressfamilie Sie erhalten haben. Lesen Sie die Dokumentation zur IPv6-Abfrage, wenn ein nennenswerter Anteil Ihres Traffics von IPv6-Besuchern stammt.
Wenn Sie dies serverseitig ausführen, bleibt ein Drittanbieter-Skript vollständig von Ihrer Seite fern, was sowohl für die Geschwindigkeit als auch für die Zuverlässigkeit zählt. Die vollständige Feldliste finden Sie in der Dokumentation zur IPv4-Abfrage.