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.
Ihren API-Schlüssel auf drei verschiedene Arten senden (und warum das wichtig ist)
Nicht jedes Tool, das mit einer API kommuniziert, handhabt die Authentifizierung auf dieselbe Weise. Deshalb akzeptiert die API einen Schlüssel über mehr als einen Mechanismus, statt alles über einen einzigen Header-Namen zu erzwingen.
Der X-API-Key-Header
Das ist die direkteste Option: ein eigener Header, der nichts als den Schlüssel enthält.
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
Manche HTTP-Clients und API-Gateways sind bereits so eingerichtet, dass sie jeder ausgehenden Anfrage ein Bearer-Token anhängen. Wenn Sie diesen Mechanismus nutzen, müssen Sie keinen zweiten, API-spezifischen Header daneben hinzufügen.
GET /v1/forward?q=Baker+Street
Authorization: Bearer mg_live_examplekey123HTTP Basic Auth
Ältere Tools und manche Server-zu-Server-Integrationen, die für andere Anbieter entwickelt wurden, erwarten Zugangsdaten per HTTP Basic Auth. Der Schlüssel wird als Benutzername übergeben, das Passwort bleibt leer.
GET /v1/forward?q=Baker+Street
Authorization: Basic bWdfbGl2ZV9leGFtcGxla2V5MTIzOg==Ein Query-Parameter für alles andere
Wenn Ihnen ein Tool überhaupt keine Kontrolle über Header gibt, etwa bei einem schnellen Test in der Adressleiste des Browsers oder bei einem Client, der nur URL-basierte Konfiguration unterstützt, kann der Schlüssel auch als Query-Parameter direkt an der Anfrage übergeben werden.
GET /v1/forward?q=Baker+Street&key=mg_live_examplekey123Warum die Wahl in der Praxis wichtig ist
Ein als Query-Parameter gesendeter Schlüssel landet leichter in Serverlogs, im Browserverlauf und in Referrer-Headern als einer, der in einem Anfrage-Header gesendet wird. Bevorzugen Sie daher eine Header-basierte Methode, wann immer der aufrufende Code darauf Einfluss hat. Alle vier Methoden funktionieren identisch mit jedem Endpunkt und jedem Kompatibilitäts-Host, sodass ein späterer Wechsel zwischen ihnen, etwa wenn Sie ein Skript von einem Browsertest zu einer richtigen Backend-Integration migrieren, nichts daran ändert, wie Kontingent oder Guthaben dem Schlüssel angerechnet werden.
Nutzung über Kompatibilitäts-Hosts hinweg
Jeder der 17 Kompatibilitäts-Hosts akzeptiert Zugangsdaten im selben Stil wie der ursprüngliche Anbieter. Ein Skript, das für die Authentifizierungskonvention eines anderen Anbieters geschrieben wurde, funktioniert daher in der Regel weiter, wenn Sie es auf den passenden Kompatibilitäts-Host von My Geocode richten, ohne die Art der Schlüsselübergabe umzuschreiben. Auf der Kompatibilitätsseite finden Sie die Liste der Hosts und welchen Stil für Zugangsdaten jeder von ihnen erwartet.
Ein Fehler, den Sie vermeiden sollten
Ein Skript mit dem Schlüssel als Query-Parameter zu testen und es in der Produktion dabei zu belassen, ist eine Gewohnheit, die sich leicht einschleicht, denn der Query-Parameter ist oft der schnellste Weg, eine erste Anfrage zum Laufen zu bringen. Wechseln Sie zu einer Header-basierten Methode, X-API-Key oder Authorization, bevor das Skript auch nur in die Nähe von Produktions-Traffic kommt oder in ein gemeinsames Repository eingecheckt wird, denn ein in einer URL sichtbarer Schlüssel landet weit eher an einem Ort, den Sie nicht beabsichtigt haben, etwa in einem Proxy-Log oder in der Verlaufsdatei eines Browsers auf einem gemeinsam genutzten Rechner.
Kein Kostenunterschied
Keine dieser Methoden ändert, wie eine Anfrage abgerechnet wird. Jede Anfrage mit dem Schlüssel wird weiterhin auf dieselbe Weise auf seine 2.500 kostenlosen Anfragen pro Tag angerechnet und darüber hinaus auf das Prepaid-Guthaben oder ein Unlimited-Paket.
Bei der Wahl der richtigen Authentifizierungsmethode geht es vor allem darum, was das aufrufende Tool bereits unterstützt, nicht um Leistung oder Kosten. Alle Details finden Sie in der Dokumentation zur Authentifizierung.