Checkliste vor dem Start

Verwaltung deiner Client-ID in der Google Cloud Console

Die Funktion zur Verwaltung der Client-ID für die Premiumoption wird vom Supportportal in die Cloud Console verlagert (Maps-Seite „Anmeldedaten“, Bereich Dienstkonten).

Der neue Client-ID-Bereich auf der Seite „Anmeldedaten“

Hinweis: Du kannst dich nicht mehr für die Google Maps Platform-Premiumoption registrieren. Auch für Neukunden ist sie nicht mehr verfügbar.

Kontrollieren, ob dein Team Zugriff auf die benötigten Ressourcen hat

Bewahre dein Begrüßungsschreiben für die Google Maps Platform-Premiumoption auf.

Bedeutung: Das Begrüßungsschreiben ist dein Starterkit und vielleicht sogar auch dein Erste-Hilfe-Set für die Google Maps Platform-Premiumoption. Es enthält wichtige Informationen wie deine Projekt-ID in der Google Cloud Console, deine Client-ID und deinen kryptografischen Schlüssel, die zur Verwendung der Premiumoption erforderlich sind. Außerdem enthält es alle Informationen, die du brauchst, um das für die Premiumoption zuständige Supportteam zu kontaktieren, wenn du technische Probleme mit einer der Google Maps APIs hast.

Die Google Cloud Console verwenden

Bedeutung: Die Google Cloud Console bietet Zugriff auf Informationen wie Nutzungsberichte, Newsfeeds und Entwicklerressourcen. Außerdem kannst du darüber Supportfälle beim Supportteam für die Premiumoption einreichen, wenn bei der Entwicklung oder Markteinführung technische Probleme auftreten.

Vor der Einführung musst du allen Entwicklern, die für die Anwendung zuständig sind, Zugriff auf die Cloud Console gewähren. So können sie sich bei technischen Problemen an den Support wenden. Außerdem ist unser Supportteam so in der Lage, sich mit den richtigen Ansprechpartnern in deiner Organisation in Verbindung zu setzen. Das kann z. B. erforderlich sein, wenn wir ungewöhnlichen Traffic oder abnormales Verhalten feststellen, durch das Probleme mit deiner Anwendung auftreten können. Wenn wir die entsprechenden Entwickler kontaktieren können, lassen sich unerwartete Ausfälle unter Umständen noch rechtzeitig verhindern.

E-Mail-Gruppen für Benachrichtigungen abonnieren

Bedeutung: Damit du hinsichtlich der Entwicklungen und Änderungen bei den Google Maps APIs immer auf dem neuesten Stand bist, empfehlen wir dir, eine oder mehrere der folgenden E-Mail-Gruppen zu abonnieren:

  • google-maps-platform-notifications: technische Updates zu den APIs und Webdiensten von Google Maps Platform, Benachrichtigungen bei Ausfällen und Funktionsankündigungen für die Plattform (ca. drei bis fünf Nachrichten pro Monat)
  • google-maps-js-api-v3-notify: neue Versionen der Google Maps JavaScript API (ca. vier Nachrichten pro Jahr)

Relevante Benachrichtigungsfeeds abonnieren

Bedeutung: Damit du hinsichtlich der Entwicklungen und Änderungen bei den Maps APIs immer auf dem aktuellen Stand bist, empfehlen wir dir, die relevanten Benachrichtigungsfeeds zu abonnieren. Eine Beschreibung hierzu findest du in den FAQ.

Du kannst auch den folgenden RSS-Feed für Google Maps Premier API Announcements: Outages, Updates, Service Notifications abonnieren:

http://google.force.com/services/xml/MapsRSS

Nummer der Supporthotline griffbereit haben

1-877-355-5787 für Kunden in den USA, +1 404-978-9282 für Kunden außerhalb der USA

Bedeutung: Über die Hotline kannst du Telefonsupport in Anspruch nehmen. Die Nummern für jedes Land findest du zusammen mit der PIN in der Cloud Console. Über die Supporthotline kannst du unserem Team technische Probleme melden. Die Hotline ist aber für Fälle reserviert, in denen es um Produktionsausfälle oder die Nichtverfügbarkeit von Diensten geht. Unsere Prioritätsstufen sind in diesem Dokument definiert.

Anwendung optimieren

Firewall konfigurieren, um Zugriff auf die Google Maps Platform-Dienste zu erlauben

Bedeutung: Google Maps Platform-Dienste verwenden verschiedene Domains, von denen einige nicht zur Domain *google.com gehören. Wenn du dich hinter einer restriktiven Firewall befindest, ist es wichtig, dass die Firewall Zugriff auf die Domains gewährt, die von den einzelnen Maps API-Diensten verwendet werden. Falls deine Firewall keinen Zugriff auf diese Domains gewährt, schlagen die API-Anfragen fehl, wodurch deine Anwendungen beeinträchtigt werden können. Eine vollständige Liste der von den Maps APIs verwendeten Domains findest du unter Liste der Google Maps-Domains.

Wir raten davon ab, Firewallrestriktionen über IP-Adressen zu verwalten, da die mit diesen Domains verknüpften IP-Adressen nicht statisch sind.

Hinweis: Bei den Google Maps Platform-Diensten werden für eingehenden und ausgehenden Traffic die Ports 80 (http) und 443 (https) verwendet. Außerdem erfordern diese Dienste GET-, POST-, PUT-, DELETE- und HEAD-Anfragen. Konfiguriere deine Firewall so, dass Traffic über diese Ports übertragen werden kann und je nach API und Anwendungsfall Anfragen zulässig sind.

APIs über den korrekten SSL-Hostnamen laden

Bedeutung: Wenn Anwendungen die Maps APIs über SSL laden, muss das über https://maps.googleapis.com erfolgen und nicht über den veralteten Hostnamen https://maps-api-ssl.google.com.

SSL-Domains zur Verwendung mit der Maps JavaScript API autorisieren

Bedeutung: Wenn die Maps JavaScript API mit einer SSL-Domain verwendet wird, ist es wichtig, dass du deine HTTPS-Domains explizit autorisiert hast, damit deine Anfragen nicht abgelehnt werden. Hinweis: Wenn du http://yourdomain.com autorisierst, wird nicht automatisch auch die entsprechende SSL-Domain https://yourdomain.com aktiviert. Du kannst die Liste der autorisierten Domains in der Google Cloud einsehen. Dazu scrollst du einfach nach unten zum Bereich Client-ID. Wenn du Fehler beheben möchtest, die bei der Verwendung der clientseitigen APIs mit einer SSL-Domain auftreten, musst du prüfen, ob Elemente deiner Seite über HTTP geladen werden. Weitere Informationen findest du unter Fehlerbehebung im Zusammenhang mit der Autorisierung von URLs für die Google Maps Platform-Premiumoption.

Richtige API-Version auswählen

Bedeutung: Vor dem Entwickeln deiner Anwendung ist es wichtig zu wissen, welche Versionen der APIs veraltet sind. Wenn du ausschließlich nicht verworfene API-Versionen verwendest, verkürzt sich nicht nur die Entwicklungszeit, sondern es ergeben sich auch geringere Folgekosten, die durch die Einstellung der verworfenen Versionen entstehen.

Insbesondere ist es wichtig, dass du das Versionierungsschema der Maps JavaScript API verstehst, damit du nicht versehentlich eine ungeeignete Version der API in deiner Umgebung verwendest.

Es kann beispielsweise sinnvoll sein, die experimentelle Version der API in deiner Entwicklungs- oder Testumgebung zu nutzen, aber wir raten unbedingt davon ab, die experimentelle Version in einer Produktionsumgebung zu verwenden. Unser SLA gilt nur für stabile Versionen der API. Daher solltest du in deiner Produktionsumgebung nur diese Versionen einsetzen.

Weitere Informationen findest du im Leitfaden zu den Maps JavaScript API-Versionen (derzeit nur in englischer Sprache verfügbar).

Zwischen clientseitigem und serverseitigem Design auswählen

Bedeutung: Die Auswahl eines client- oder serverseitigen Ansatzes ist eine architektonische Entscheidung, die von größter Bedeutung für die Stabilität und Ausbaufähigkeit deiner Anwendung ist. Im Wesentlichen sollte für die offline (d. h. außerhalb deiner Anwendung) stattfindende Vor- und Nachbearbeitung von Datensätzen ein serverseitiger Ansatz gewählt werden. Im Gegensatz dazu sollte für die Teile deiner Anwendungen, bei denen es Nutzerinteraktionen gibt (d. h. bei denen in Echtzeit Nutzeranfragen verarbeitet werden), ein clientseitiger Ansatz gewählt werden.

Die Wahl eines serverseitigen Ansatzes, obwohl ein clientseitiger Ansatz erforderlich ist, ist die Hauptursache für überschrittene Kontingente und damit fehlerhafte Anwendungen. Wir empfehlen dir dringend, dich mit den Geocodierungsstrategien vertraut zu machen, bevor du Anwendungen entwickelst oder startest, die auf serverseitigen Aufrufen beruhen.

Kontingentnutzung optimieren

Bedeutung: Wenn du weißt, wie deine Anwendung das Kontingent bzw. die sogenannten Maps APIs Credits nutzt, kannst du deine Kosten senken. Wenn du beispielsweise die Maps JavaScript API verwendest, verbraucht deine Anwendung Maps API Credits für jeden Kartenaufruf. Informationen hierzu findest du in der Anleitung zu Nutzungsgebühren und ‐limits für die Premiumoption.

Nutzung deiner Webdienstkontingente verwalten

Bedeutung: Standardmäßig beläuft sich das übergreifende Webdienstkontingent auf 100.000 tägliche kostenfreie Anfragen. Eine ausführlichere Kontingentaufschlüsselung nach APIs findest du in der Dokumentation zu Nutzungslimits. Prüfe deine Kontingente in der Cloud Console oder reiche einen Supportfall ein, wenn es Probleme mit dem Kontingent gibt.

Bevor du deinen Dienst einführst, musst du dich mit den verschiedenen Fehlern für das Überschreiten von Kontingenten vertraut machen, z. B. OVER_QUERY_LIMIT oder User Rate Limit Exceeded. Außerdem ist es wichtig, dass du in deiner Anwendung die richtige Logik anwendest, um auf entsprechende Fehler zu reagieren. Lies dir zuerst die FAQ zu Nutzungslimits durch. Informationen zu den von den einzelnen APIs zurückgegebenen Statuscodes findest du im Entwicklerleitfaden für die betreffende API, beispielsweise im Leitfaden zu Directions API-Statuscodes. Wenn du diese Konzepte verstehst und implementierst, wird das Risiko erheblich verringert, dass deine Anwendung dein verfügbares Kontingent überschreitet, von Google blockiert wird und/oder Fehler auftreten.

Belastungstests bei deiner App durchführen

Bedeutung: Du solltest Belastungstests für deine Anwendung durchführen, um sicherzustellen, dass auch eine große Anzahl von Anfragen verarbeitet werden kann, ohne dass die Kontingente für die Maps APIs überschritten werden.

Belastungstests mit aktiven Google-Diensten führen dazu, dass die zulässigen Kontingente überschritten werden und deine Anwendung von Google gesperrt wird. Google Maps Platform kann sehr hohe Volumina handhaben. 2012 verarbeitete „Auf den Spuren des Weihnachtsmanns“ 1.600.000 Anfragen pro Sekunde. Daher ist es nicht erforderlich, einen Belastungstest bei Google-Diensten durchzuführen. Durch einen Belastungstest deiner Anwendung soll vielmehr sichergestellt werden, dass deine Anwendung hohe Anfragevolumina bewältigen kann, ohne dass deine Kontingente für die Maps APIs überschritten werden. Beispiel: Wenn sich dein Kontingent für die Geocoding API auf 20 Abfragen pro Sekunde beläuft, sollte durch einen Belastungstest sichergestellt werden, dass deine Anwendung 600 Abfragen pro Sekunde verarbeiten kann, ohne mehr als 20 Abfragen pro Sekunde an die Geocoding API zu senden.

Um das zu gewährleisten, sollte der Belastungstest bei einer Pseudo-API (Fake-API) vorgenommen werden – einem Dienst, der ohne Einbeziehung von Google Maps Platform eine große Anzahl an Anfragen aufnehmen und mit gültigen Antworten beantworten kann. So kannst du Belastungstests für deine Anwendung durchführen, ohne das Risiko einzugehen, dass sie von der Google Maps Platform gesperrt wird.

Sieh dir dieses Beispiel für eine Pseudo-API an, die als kleine Google App Engine-Anwendung implementiert wurde. Du kannst dieses Beispiel in deine eigene App Engine-Anwendung hochladen, nachdem du dich unter appengine.google.com registriert hast. Lasse dann deine Anwendung Anfragen an diese Adresse anstatt an maps.googleapis.com senden.

Die standardmäßigen (kostenlosen) Kontingente für die App Engine sollten im Allgemeinen ausreichen, um weit über deine Kontingente für die Webdienste der Maps APIs hinaus einen Belastungstest deiner Anwendung durchzuführen. Deine Anwendung muss den richtigen User-Agent-Header festlegen, um die Antwortkomprimierung zu aktivieren. Das ist wichtig, um eine effiziente Bandbreitennutzung zu gewährleisten, was eine entscheidende Voraussetzung für eine App Engine-Anwendung ist, die ein hohes Volumen an Nur-Text-Antworten (JSON/XML) verarbeitet. Wenn du ein höheres Kontingent für deine App Engine-Anwendung benötigst, kannst du auch die Abrechnung aktivieren, obwohl das nur selten erforderlich sein sollte.

Anwendung von einer Standard- zu einer Premium-Lizenz migrieren

Client-ID oder API-Schlüssel in API-Anfragen einfügen

Begründung: Einer der wichtigsten Schritte für deine Anwendung besteht darin, deine Client-ID (gme-yourclientid) oder deinen API-Schlüssel in deinen API-Anfragen anzugeben, der in etwa so aussieht: AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0. Durch die Client-ID bzw. den API-Schlüssel werden deine Anfragen als Anfrage an die Google Maps Platform-Premiumoption identifiziert.

Du musst deine Client-ID oder deinen API-Schlüssel in deine Anwendungen aufnehmen, um alle Funktionen der Premiumoption nutzen zu können. Außerdem ist die Angabe deiner Client-ID oder deines API-Schlüssels erforderlich, um unseren technischen Support in Anspruch nehmen zu können und um sicherzustellen, dass deine Anwendung durch unser SLA abgedeckt ist.

Für die meisten APIs kannst du wählen, ob du eine Client-ID oder einen API-Schlüssel verwenden möchtest. Deine Client-ID findest du im Begrüßungsschreiben, das an den bzw. die Hauptansprechpartner in deinem Unternehmen gesendet wurde. Mit der Google Cloud Console kannst du eigene API-Schlüssel generieren.

Ausführliche Informationen findest du in der Anleitung zur Authentifizierung und Autorisierung.

API-Schlüssel oder Client-ID (nicht beides) in API-Anfragen einfügen

Bedeutung: Um die Maps JavaScript API korrekt zu laden oder eine Anfrage an andere Google Maps APIs zu senden, musst du entweder die Client-ID oder den API-Schlüssel einfügen, aber nicht beides. Wenn du eine Client-ID verwenden möchtest, musst du alle key-Parameter entfernen. Wenn deine Anfrage sowohl eine Client-ID als auch einen Schlüssel enthält, können unerwartete Funktionsweisen oder Fehler in der Anwendung auftreten.

Ausführliche Informationen zum richtigen Format von Anfragen pro API im Rahmen der Premiumoption findest du im Leitfaden zur Authentifizierung und Autorisierung.

Bei Verwendung einer Client-ID: Domains für die Verwendung mit der Maps JavaScript API autorisieren

Bedeutung: Um zu verhindern, dass nicht autorisierte Websites deine Client-ID nutzen, musst du für die Google Maps JavaScript API bei unserem Supportteam die Domains aller Websites autorisieren, die deine Client-ID verwenden. Wenn du anstelle der Client-ID einen API-Schlüssel verwendest, ist keine URL-Registrierung erforderlich. Wenn keine Übereinstimmung zwischen den autorisierten URLs und der Website besteht, die versucht, deine Client-ID zu nutzen, kann deine Website die API mit deiner Client-ID nicht verwenden. Du kannst jederzeit Domains autorisieren. Stelle deshalb vor dem Start sicher, dass du die Domains für alle deine Websites autorisiert hast.

Du kannst die Liste der autorisierten Domains in der Cloud Console aufrufen, indem du auf der Seite Anmeldedaten zu Client-ID scrollst.

Sollten bei der Autorisierung Probleme auftreten, empfehlen wir dir, zuerst im Leitfaden zur Fehlerbehebung im Zusammenhang mit der Autorisierung nachzulesen, bevor du einen Supportfall einreichst.

Bei Verwendung einer Client-ID: Webdienstanfragen mit einer mit deinem privaten kryptografischen Schlüssel generierten Signatur signieren

Bedeutung: Dein privater kryptografischer Schlüssel wird verwendet, um digitale Signaturen zu generieren, anhand derer Google erkennt, dass deine Anfragen von einer vertrauenswürdigen Quelle stammen. Unsere Web Service APIs erfordern, dass du deinen Anfragen eine digitale Signatur hinzufügst, wenn du eine Client-ID für die Authentifizierung verwendest. Hierdurch erhält deine Anfrage eine zusätzliche Sicherheitsstufe, durch die das deiner Client-ID zugeordnete Kontingent besser geschützt ist. Deinen kryptografischen Schlüssel (z. B. vNIXE0xscrmjlyV-12Nj_BvUPaw=) findest du im Begrüßungsschreiben, das an den bzw. die Hauptansprechpartner in deinem Unternehmen gesendet wurde.

Hinweis: Der kryptografische Schlüssel wird verwendet, um Signaturen zu generieren. Hänge ihn nicht als Signatur an deine Anfragen an. Dein kryptografischer Schlüssel ist mit der PIN deiner Bankkarte vergleichbar, die du am Geldautomaten eingeben musst. Er wird als Authentifizierungsmittel für den Zugriff auf dein Konto verwendet und sollte nie für nicht vertrauenswürdige Quellen zugänglich sein. Webdienstanfragen im Rahmen der Premiumoption, die nicht ordnungsgemäß signiert sind, werden von unseren Servern abgelehnt. Daher ist es wichtig, dass deine Anwendung Anfragen vor dem Start ordnungsgemäß signiert. Informationen findest du in der Anleitung zur Authentifizierung und Autorisierung.

Anwendungsnutzung erfassen

Bedeutung: Als Kunde mit Premiumoption hast du Zugriff auf ausführliche Berichte zur Nutzung deiner Anwendung, einschließlich erfasster Anfragen, verbrauchter Guthaben und zurückgegebener Fehler. Informationen findest du in der Anleitung unter Berichte.

Der Parameter channel ist optional. Du kannst mit ihm die Nutzung unter deiner Client-ID erfassen, indem du jeder deiner Anwendungen einen anderen Kanal zuweist. Kanalparameter müssen nicht unter deiner Client-ID registriert werden. Wenn du den Kanalparameter deiner API-Anfrage hinzufügst, werden 1–2 Tage nach der Implementierung die Nutzungsergebnisse pro Kanal in deinen Nutzungsberichten im Supportportal angezeigt. Du entscheidest, wo deine Kanäle implementiert werden, und somit auch, wie die Nutzung aggregiert wird. Die Entscheidung, ob du Kanalparameter zur Nachverfolgung der Anwendungsnutzung in deine Anwendung einbinden möchtest, sollte vor dem Start fallen.

Der Parameter channel muss das folgende Format haben:

  • Er muss eine alphanumerische ASCII-Zeichenfolge sein.
  • Punkte (.), Unterstriche (_) und Bindestriche (-) sind zulässig.
  • Beim Parameter channel wird nicht zwischen Groß-, Klein- oder einer Kombination aus Groß- und Kleinbuchstaben unterschieden. Unterschiedliche Schreibweisen beim Parameter channel werden in der entsprechenden kleingeschriebenen Variante zusammengeführt. So wird beispielsweise die Nutzung im Kanal CUSTOMER mit der Nutzung im Kanal customer kombiniert.

Du kannst bis zu 2.000 unterschiedliche Kanäle pro Client-ID implementieren.

Um den Parameter channel zu verwenden, füge ihn zusammen mit dem Parameter client, der für die Übergabe der Client-ID verwendet wird, in die Anfrage-URL ein.

Beachte, dass der Kanalparameter ein pro Anwendung statisch zugewiesener Wert sein muss. Er darf nicht dynamisch generiert und zur Nachverfolgung individueller Nutzer verwendet werden.