Où gérer votre ID client dans Google Cloud Console ?
La fonctionnalité de gestion des ID client du forfait Premium est transférée du portail d'assistance vers Cloud Console sur la page "Identifiants" de Maps, dans la section Comptes de service.
Remarque : Il n'est plus possible de s'inscrire au forfait Premium Google Maps Platform, qui n'est plus disponible non plus pour les nouveaux clients.
Assurez-vous que votre équipe dispose des ressources nécessaires
Conservez votre courrier de bienvenue concernant le forfait Premium Google Maps Platform en lieu sûr
Pourquoi est-ce important ? Votre courrier de bienvenue correspond à votre kit de démarrage pour le forfait Premium Google Maps Platform, mais il peut aussi vous servir de kit de premiers secours. Il contient des informations essentielles telles que l'ID de votre projet Google Cloud Console, votre ID client et votre clé cryptographique, qui sont nécessaires pour commencer à utiliser le forfait Premium. Il inclut également toutes les informations dont vous avez besoin pour contacter l'équipe d'assistance du forfait Premium si vous rencontrez des problèmes techniques avec l'une des API Google Maps.
Utiliser Google Cloud Console
Pourquoi est-ce important ? Google Cloud Console contient des informations comme les rapports d'utilisation, les flux d'actualité et des ressources pour les développeurs. Surtout, Cloud Console vous permet d'envoyer des demandes d'assistance à l'équipe d'assistance du forfait Premium en cas de problèmes techniques lors du développement ou du lancement.
Avant le lancement, activez l'accès à Cloud Console pour tous les développeurs chargés de la maintenance de votre application. En cas de problèmes techniques, Cloud Console permet aux membres de votre équipe de demander de l'aide et à l'équipe d'assistance de contacter les personnes concernées dans votre organisation. Par exemple, l'équipe d'assistance peut avoir besoin de contacter votre organisation si elle détecte un trafic ou un comportement anormal qui risque d'interrompre votre application. Si nous sommes assurés de pouvoir contacter les développeurs concernés, nous pourrons prévenir les pannes au lieu de les subir.
Abonnez-vous aux groupes de notification par e-mail
Pourquoi est-ce important ? Pour vous tenir au courant des développements et des changements concernant les API Google Maps, nous vous recommandons de vous abonner aux groupes suivants ou à l'un des deux :
- google-maps-platform-notifications : informations techniques sur les API et les services Web Google Maps Platform, notifications d'interruption et annonces de fonctionnalités sur la plate-forme (environ trois à cinq messages par mois).
- google-maps-js-api-v3-notify : nouvelles versions de l'API Google Maps JavaScript (environ quatre messages par an).
Abonnez-vous à des flux de notification pertinents
Pourquoi est-ce important ? Pour vous tenir au courant des développements et des changements au sein des API Google Maps, nous vous recommandons de vous abonner aux flux de notification qui vous intéressent, comme indiqué dans les questions fréquentes.
Vous pouvez également vous abonner au flux RSS suivant pour recevoir les annonces concernant l'API Google Maps Premier : indisponibilités, mises à jour, notifications de service :
http://google.force.com/services/xml/MapsRSS
Gardez le numéro de l'assistance téléphonique à portée de main
1-877-355-5787 pour les clients aux États-Unis, +1 404-978-9282 en dehors des États-Unis
Pourquoi est-ce important ? L'assistance téléphonique vous permet d'appeler l'équipe qui pourra vous aider. Les numéros de l'assistance pour chaque pays sont disponibles dans Cloud Console, avec le code. Même si vous pouvez utiliser l'assistance téléphonique pour signaler des problèmes techniques à notre équipe, cette ligne est réservée aux cas de panne de production ou de service inutilisable. Nos niveaux de priorité sont définis dans ce document.
Optimisez votre application
Configurez un pare-feu pour autoriser l'accès aux services Google Maps Platform
Pourquoi est-ce important ? Les services Google Maps Platform utilisent différents domaines, dont certains n'appartiennent pas au domaine *google.com. Si vous vous trouvez derrière un pare-feu restrictif, il est important d'autoriser l'accès aux domaines utilisés par chaque service de l'API Google Maps. En effet, si votre pare-feu n'autorise pas l'accès à ces domaines, les requêtes API échoueront, ce qui peut interrompre vos applications. Consultez la liste complète des domaines utilisés par les API Google Maps.
Nous vous déconseillons de gérer les restrictions du pare-feu par adresse IP, car les adresses IP associées à ces domaines ne sont pas statiques.
Remarque : Les services Google Maps Platform utilisent les ports 80 (http) et 443 (https) pour le trafic entrant et sortant. Ces services nécessitent également des requêtes GET, POST, PUT, DELETE et HEAD. Configurez votre pare-feu de façon à autoriser le trafic sur ces ports et les requêtes, en fonction de l'API et du cas d'utilisation.
Chargez les API sur le nom d'hôte SSL approprié
Pourquoi est-ce important ? Les applications qui chargent les API Google Maps via SSL doivent le faire à partir de https://maps.googleapis.com au lieu de https://maps-api-ssl.google.com (ancien nom d'hôte).
Autorisez vos domaines SSL à utiliser avec l'API Maps JavaScript
Pourquoi est-ce important ? Lorsque vous utilisez l'API Maps JavaScript avec un domaine SSL, vous devez absolument avoir autorisé vos domaines HTTPS de manière explicite pour que vos requêtes ne soient pas refusées. Notez qu'autoriser http://yourdomain.com n'active pas automatiquement son équivalent SSL, https://yourdomain.com. Consultez la liste de vos domaines autorisés dans Cloud Console en faisant défiler la page jusqu'à la section ID client. Pour résoudre les problèmes liés à l'utilisation d'API côté client avec un domaine SSL, vérifiez au préalable si certains éléments de votre page sont chargés via HTTP. Consultez le guide pour résoudre les problèmes d'autorisation.
Sélectionnez la version d'API appropriée
Pourquoi est-ce important ? Avant de développer votre application, vous devez identifier les versions d'API qui sont obsolètes. En choisissant d'utiliser les versions non obsolètes des API pour le développement, vous économiserez du temps et de l'argent à terme lorsque les versions obsolètes ne seront plus disponibles.
Plus particulièrement, il est important de comprendre le schéma de version utilisé par l'API Maps JavaScript pour éviter d'utiliser accidentellement une version inadaptée de l'API dans votre environnement.
Par exemple, vous pourrez peut-être utiliser la version expérimentale de l'API dans votre environnement de développement ou de test, mais nous vous déconseillons fortement de l'utiliser dans un environnement de production. Notre contrat de niveau de service ne s'applique qu'aux versions stables de l'API. Vous ne devez donc utiliser que des versions stables dans votre environnement de production.
Consultez le guide des versions de l'API Maps JavaScript.
Choisissez une conception côté client ou côté serveur
Pourquoi est-ce important ? Le choix d'une approche côté client ou côté serveur est une décision d'architecture qui est absolument essentielle pour la stabilité et l'évolutivité de votre application. De manière générale, une approche côté serveur doit être utilisée pour le prétraitement et le post-traitement des enregistrements hors connexion (en dehors de votre application). À l'inverse, une approche côté client doit être utilisée pour les parties de vos applications qui interagissent avec vos utilisateurs (par exemple, traitement en temps réel des requêtes soumises par l'utilisateur).
Le déploiement d'une approche côté serveur là où une approche côté client devrait être utilisée est la cause principale de dépassement des quotas et, par conséquent, de l'interruption des applications. Nous vous recommandons vivement de consulter les stratégies de geocoding avant de concevoir ou de lancer des applications qui reposent sur des appels côté serveur.
Optimisez l'utilisation de votre quota
Pourquoi est-ce important ? Comprendre comment votre application utilise le quota (ou les crédits de l'API Google Maps) vous aidera à réduire le montant de votre facture. Par exemple, si vous utilisez l'API Maps JavaScript, votre application consomme des crédits d'API Google Maps pour chaque chargement de carte. Consultez le guide sur les tarifs et limites d'utilisation du forfait Premium.
Gérez l'utilisation du quota des services Web
Pourquoi est-ce important ? Par défaut, le quota des services Web partagés est fixé à
Avant de lancer votre service, il est important de comprendre les différentes erreurs liées aux quotas (par exemple OVER_QUERY_LIMIT, User Rate Limit
Exceeded), et de paramétrer la logique appropriée dans votre application pour pouvoir répondre à de telles erreurs en cas de dépassement de votre quota. Commencez par lire les questions fréquentes sur les limites d'utilisation.
Pour plus d'informations sur les codes d'état affichés par chaque API, consultez le guide du développeur de l'API concernée. Par exemple, reportez-vous au guide Codes d'état de l'API Directions.
Si vous comprenez et appliquez ces concepts, vous réduirez considérablement les risques de dépassement des quotas autorisés, de blocage par Google et/ou d'interruption.
Effectuez des tests de charge de votre application
Pourquoi est-ce important ? Utilisez les tests de charge de votre application pour vous assurer qu'elle peut traiter de gros volumes de requêtes sans dépasser les quotas définis pour les API Google Maps.
Effectuer des tests de charge par rapport aux services Google actuels pourra entraîner le dépassement du quota autorisé de votre application et son blocage par Google. Google Maps Platform peut gérer des volumes très importants. En 2012, Sur la piste du Père Noël a traité 1 600 000 requêtes par seconde. Il est donc inutile d'effectuer des tests de charge par rapport aux services Google. En revanche, les tests de charge de votre application doivent garantir que celle-ci est capable de gérer des volumes de requêtes élevés sans dépasser les quotas définis pour les API Google Maps. Par exemple, si votre quota pour l'API Geocoding est de 20 RPS (requêtes par seconde), le test de charge de votre application doit garantir qu'elle peut traiter 600 RPS sans envoyer plus de 20 RPS à l'API Geocoding.
Pour y parvenir, les tests de charge doivent être effectués par rapport à une API factice, un service capable d'absorber de grandes quantités de requêtes et d'y répondre de manière appropriée, sans impliquer Google Maps Platform. Vous pouvez ainsi tester la charge de votre application sans risquer d'être bloqué par Google Maps Platform.
Consultez cet exemple d'API factice intégré sous la forme d'une petite application Google App Engine. Vous pouvez importer cet exemple dans votre propre application App Engine (après l'avoir enregistrée sur appengine.google.com) et faire en sorte que votre application envoie les requêtes à cette adresse plutôt que sur maps.googleapis.com.
Les quotas App Engine par défaut (gratuits) sont généralement suffisants pour effectuer un test de charge de votre application, bien au-delà des quotas dédiés aux services Web des API Google Maps. Assurez-vous que votre application définit l'en-tête User-Agent approprié pour activer la compression des réponses. Cette étape est essentielle : elle garantit une utilisation efficace de la bande passante, ce qui est particulièrement important pour une application App Engine traitant un gros volume de réponses en texte brut (JSON/XML). Dans les rares cas où cela s'avérerait nécessaire, vous pouvez augmenter le quota de votre application App Engine en activant la facturation.
Passez d'une licence Standard à une licence Premium pour votre application
Incluez votre ID client ou votre clé API dans vos requêtes API
Pourquoi est-ce important ? Pour votre application, vous devez impérativement inclure votre ID client (gme-yourclientid) ou votre clé API (qui ressemble à AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0) dans vos requêtes API. L'ID client ou la clé API permettent d'identifier vos requêtes comme étant associées au forfait Premium Google Maps Platform.
Vous devez inclure votre ID client ou votre clé API dans vos applications pour pouvoir profiter de toutes les fonctionnalités propres au forfait Premium. Il est également nécessaire d'inclure votre ID client ou votre clé API pour bénéficier d'une assistance technique et pour que votre application soit couverte par notre contrat de niveau de service
Pour la plupart des API, vous pouvez choisir entre utiliser un ID client ou une clé API. Votre ID client est inclus dans le courrier de bienvenue qui a été envoyé aux contacts principaux de votre organisation. Vous pouvez générer vos propres clés API dans Google Cloud Console.
Pour plus d'informations, consultez le guide sur l'authentification et l'autorisation.
Incluez la clé API ou l'ID client dans les requêtes API, mais pas les deux
Pourquoi est-ce important ? Pour charger correctement l'API Maps JavaScript ou pour envoyer une requête à d'autres API Google Maps, vous devez inclure soit votre ID client, soit votre clé API, mais pas les deux. Si vous choisissez d'utiliser un ID client, vous devez supprimer tous les paramètres key. Si votre requête inclut à la fois un ID client et une clé, votre application risque de générer des erreurs ou un comportement inattendu.
Suivez le guide sur l'authentification et l'autorisation pour savoir comment mettre en forme les requêtes du forfait Premium par API.
Si vous utilisez un ID client, autorisez l'utilisation de vos domaines avec l'API Maps JavaScript
Pourquoi est-ce important ? Pour éviter que des sites non autorisés utilisent votre ID client, l'API Maps JavaScript vous demande d'autoriser tous les domaines auprès de notre équipe d'assistance, pour tous les sites qui utiliseront votre ID client. (L'enregistrement des URL n'est pas obligatoire si vous utilisez une clé API au lieu d'un ID client.) Si le site qui tente d'utiliser votre ID client ne correspond à aucune URL autorisée, votre site ne pourra pas utiliser l'API avec cet ID client. Sachant que vous pouvez autoriser des domaines à tout moment, nous vous invitons à autoriser ceux de tous vos sites avant le lancement.
Vous pouvez consulter la liste de vos domaines autorisés dans Cloud Console en accédant à la page Identifiants et en la faisant défiler jusqu'à la section ID client.
Pour les problèmes d'autorisation, nous vous recommandons de consulter le guide sur la résolution des problèmes liés à l'autorisation avant d'envoyer une demande d'assistance.
Si vous utilisez un ID client, signez les requêtes de service Web à l'aide d'une signature générée avec votre clé cryptographique privée
Pourquoi est-ce important ? Votre clé cryptographique privée permet de générer des signatures numériques indiquant à Google que vos requêtes proviennent d'une source fiable. Si vous vous authentifiez via un ID client, vous devez ajouter une signature numérique à vos requêtes pour utiliser nos API de services Web. Votre requête bénéficie ainsi d'un niveau de sécurité supplémentaire qui protège davantage le quota associé à votre ID client. Votre clé cryptographique (par exemple, vNIXE0xscrmjlyV-12Nj_BvUPaw=) figure dans le courrier de bienvenue envoyé aux contacts principaux de votre organisation.
Remarque : La clé cryptographique permet de générer des signatures. Ne l'ajoutez pas à vos requêtes en tant que signature à proprement parler. Votre clé cryptographique fonctionne comme le code secret de votre carte bancaire. Elle vous permet de vous authentifier pour accéder à votre compte, et vous ne devez jamais la partager ouvertement ni la communiquer à des sources non fiables. Les requêtes de services Web du forfait Premium qui ne sont pas correctement signées seront refusées par nos serveurs. Il est donc essentiel que votre application signe correctement la requête avant son lancement. Consultez le guide sur l'authentification et l'autorisation.
Suivez l'utilisation de votre application
Pourquoi est-ce important ? En tant que client du forfait Premium, vous avez accès à des rapports détaillés sur l'utilisation de votre application, y compris sur les requêtes effectuées, les crédits utilisés, les erreurs affichées et d'autres informations. Consultez le guide sur les rapports.
Le paramètre channel (facultatif) vous permet de suivre l'utilisation via votre ID client en attribuant un canal distinct à chacune de vos applications. Vous n'avez pas besoin d'enregistrer les paramètres channel sous votre ID client. Ajoutez-les à votre requête API pour afficher les résultats sur l'utilisation par canal dans les rapports sur l'utilisation du portail d'assistance un ou deux jours après l'intégration. C'est à vous de décider où vos paramètres channel doivent être intégrés, et donc comment votre utilisation doit être cumulée. Décidez avant le lancement si votre application doit ou non intégrer des paramètres channel pour suivre l'utilisation de votre application.
Le paramètre channel doit utiliser le format suivant :
- Il doit s'agir d'une chaîne alphanumérique ASCII.
- Les points (
.), les traits de soulignement (_) et les traits d'union (-) sont autorisés. - Le paramètre
channeln'est pas sensible à la casse. Les valeurs en majuscules, en minuscules et dans une combinaison des deux sont donc fusionnées dans leur équivalent en minuscules. Par exemple, l'utilisation sur le canalCUSTOMERest combinée à celle sur le canalcustomer.
Vous pouvez intégrer jusqu'à 2 000 paramètres channel distincts par ID client.
Pour utiliser le paramètre channel, incluez-le dans l'URL de la requête avec le paramètre client utilisé pour transmettre l'ID client.
Notez que le paramètre channel doit correspondre à une valeur attribuée statiquement par application. Il ne doit pas être généré dynamiquement ni utilisé pour suivre des utilisateurs individuels.