Liste des points à vérifier avant le lancement de Google Maps APIs for Work

Cette page concerne uniquement les clients qui possèdent une ancienne licence Maps APIs for Work ou Maps API for Business. Cette page ne s'applique pas aux clients qui disposent du nouveau Google Maps APIs Premium Plan, sorti en janvier 2016.

  1. S'assurer que votre équipe a accès aux ressources nécessaires
    1. Réception de la lettre de bienvenue Google Maps APIs for Work
    2. Accéder à Google Cloud Support Portal et l'utiliser
    3. S'abonner à des flux de notification pertinents
    4. Garder le numéro de l'assistance téléphonique à portée de main
  2. Optimisation des applications
    1. Configurer le pare-feu pour autoriser l'accès aux services Google Maps APIs
    2. Charger les API via SSL
    3. Utiliser Maps API côté client dans vos domaines SSL
    4. Sélectionner la bonne version d'API
    5. Optimiser l'utilisation des vues de page
    6. Conception côté client contre conception côté serveur : Choisir l'approche adaptée à votre cas d'utilisation
    7. Quota et gestion des services Web
    8. Tests de charge
  3. Migrer d'une implémentation gratuite vers une implémentation Google Maps APIs for Work
    1. Autorisation des domaines
    2. Intégration de votre ID client
    3. Utiliser la clé cryptographique pour signer des requêtes de services Web
    4. Suivre l'utilisation des applications et le paramètre channel
    5. Supprimer des paramètres obsolètes de vos requêtes API

S'assurer que votre équipe a accès aux ressources nécessaires

Réception de la lettre de bienvenue Google Maps APIs for Work

Pourquoi c'est important : Votre lettre de bienvenue est votre kit de démarrage de Google Maps APIs for Work et peut-être aussi votre kit de premiers secours. Elle contient des informations importantes comme votre ID client et votre clé cryptographique, qui sont nécessaires pour commencer à utiliser les Google Maps APIs. Elle contient également toutes les informations utiles pour contacter l'équipe Google Cloud Support en cas de problèmes techniques avec certaines Google Maps APIs.

Accéder à Google Cloud Support Portal et l'utiliser

Pourquoi c'est important : Le portail de support vous donne accès à des informations comme les rapports d'utilisation, les flux d'actualité et des ressources utiles pour les développeurs. Plus important encore, il vous permettra de soumettre des demandes d'assistance auprès de l'équipe de support Google Maps APIs en cas de problèmes techniques au cours du développement ou du lancement. Vous pouvez accéder au portail de support à l'adresse URL suivante :

https://google.secure.force.com/

Avant le lancement, veuillez prendre le temps d'activer l'accès au portail de support pour tous les développeurs responsables de la maintenance de votre application. Si vous rencontrez des problèmes techniques, l'accès au portail de support aura le double avantage de permettre aux membres de votre équipe de contacter le support et à l'équipe de support de contacter les personnes concernées de votre organisation. Par exemple, l'équipe de support peut avoir besoin de contacter votre organisation si elle détecte un trafic ou un comportement anormal qui risque d'endommager votre application. L'assurance de pouvoir contacter les développeurs concernés peut permettre de prévenir les pannes au lieu de les subir. Si vous n'avez pas accès au portail de support, faites une demande d'accès ici :

Demander un compte Google Cloud Support Portal

S'abonner à des flux de notification pertinents

Pourquoi c'est important : Pour vous tenir au courant des développements et des changements liés aux Google Maps APIs, nous vous recommandons de vous abonner aux flux de notification qui vous concernent. Vous pouvez vous abonner au Blog Google Geo Developers ainsi qu'aux Google Groups correspondant aux API que vous utilisez, comme décrit ici :

https://developers.google.com/maps/faq#notify

Veuillez prendre un instant pour vous abonner aux groupes de notification pour les API que vous utilisez ou que vous prévoyez d'utiliser. Vous pouvez également vous abonner au flux RSS suivant :

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

pour recevoir des mises à jour des équipes de support Google Maps APIs.

Garder 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 c'est important : L'assistance téléphonique vous permet d'appeler Google Cloud Support Portal. Ajoutez cette page aux favoris pour disposer du numéro de téléphone du support le plus à jour. Veuillez noter que 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 sur :

https://support.google.com/work/answer/184028

Optimisation des applications

Configurer le pare-feu pour autoriser l'accès aux services Google Maps APIs

Pourquoi c'est important : les services Google Maps APIs utilisent une grande variété de domaines, dont certains qui 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 Maps API. En effet, si votre pare-feu n'autorise pas l'accès à ces domaines, les requêtes d'API échoueront, ce qui peut interrompre vos applications. La liste complète des domaines utilisés par les Maps API est disponible sur le portail de support :

  1. Connectez-vous au Google Cloud Support Portal.
    Le portail de support est disponible uniquement aux clients disposant de Google Maps APIs Premium Plan ou d'une licence antérieure de Google Maps APIs for Work ou Google Maps for Business.
  2. Naviguez jusqu'à l'onglet Resources.
  3. Sélectionnez List of domains used by the Google Maps APIs family.
  4. Autorisez vos applications à accéder aux domaines répertoriés.

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 APIs 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, ainsi que les requêtes, en fonction de l'API et du cas d'utilisation.

Charger les API via SSL

Pourquoi c'est important : Les applications qui chargent Maps JavaScript API, les API de services Web ou les API d'image via SSL doivent le faire depuis https://maps.googleapis.com et non depuis l'ancien nom d'hôte, https://maps-api-ssl.google.com.

Utiliser Maps API côté client dans vos domaines SSL

Pourquoi c'est important : Lorsque vous utilisez une API côté client avec un domaine SSL, il est essentiel d'avoir autorisé explicitement vos domaines HTTPS pour vous assurer que vos requêtes ne seront pas rejetées. Veuillez noter qu'autoriser http://yourdomain.com n'active pas automatiquement son équivalent SSL, https://yourdomain.com. Vous pouvez vérifier votre liste de domaines autorisés sur le Google Cloud Support Portal en cliquant sur le lien Maps: Manage Client ID dans le menu de navigation situé à gauche. Pour résoudre des problèmes liés à l'utilisation d'API côté client avec un domaine SSL, nous vous incitons à vérifier au préalable si certains éléments de votre page sont chargés via HTTP. Voir aussi l'article Résolution des problèmes d'autorisation pour les implémentations de Google Maps APIs for Work.

Sélectionner la bonne version d'API

Pourquoi c'est important : Avant de développer votre application, il est important de connaître les versions des 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.

Il est aussi important de comprendre le schéma de version de l'API afin d'éviter d'utiliser accidentellement une version inadaptée de l'API dans votre environnement :

https://developers.google.com/maps/documentation/javascript/versions

Par exemple, il peut être possible d'utiliser la version quotidienne (Experimental, par exemple) 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.

Optimiser l'utilisation des vues de page

Pourquoi c'est important : Si vous n'affichez pas toujours une carte Google sur votre site, pourquoi payer ce service ? Pour utiliser plus efficacement vos vues de page, nous vous suggérons de charger les Maps API de manière asynchrone sur les pages où vous affichez une carte. Vous pourrez ainsi réduire fortement le nombre de vues de page achetées et consommées par vos applications. Rappelez-vous que chaque fois qu'une page qui charge l'API est actualisée, une vue de page supplémentaire est générée. Par conséquent, nous vous recommandons lors de la conception de votre application, que le site qui charge l'API n'actualise les pages que lorsque cela est absolument nécessaire.

Conception côté client contre conception côté serveur : Choisir l'approche adaptée à votre cas d'utilisation

Pourquoi c'est important : Le choix d'une approche côté client ou côté serveur est une décision d'architecture et 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 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 le document Stratégies de géocodage avant de concevoir ou de lancer des applications reposant sur des appels côté serveur.

Quota et gestion des services Web

Pourquoi c'est important : Par défaut, les quotas de services Web s'élèvent à 100 000 requêtes par 24 heures. Pour une décomposition plus détaillée des quotas par API, consultez la documentation sur les limites d'utilisation. Pour connaître le quota associé à votre ID client, complétez une demande d'assistance. Avant de lancer votre service, il est important de comprendre les différentes erreurs liées aux quotas (Ex. 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 l'article Limites d'utilisation des services Web Google Maps APIs. La compréhension et la mise en œuvre de ces concepts vous permettra de réduire considérablement les risques de dépassement des quotas autorisés, de blocage par Google et/ou d'interruption.

Tests de charge

Pourquoi c'est important : 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.

Les Google Maps APIs peuvent gérer de très grands volumes. En 2012, Santa Tracker a traité 1 600 000 requêtes par seconde. Il est donc inutile d'effecteur 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 de grands volumes de requêtes sans dépasser les quotas définis pour les Maps API. Par exemple, si votre quota pour Google Maps Geocoding API est de 20 QPS (requêtes par seconde), le test de charge de votre application doit garantir que l'application peut traiter 600 QPS sans envoyer plus de 20 QPS à Google Maps Geocoding API.

Pour y parvenir, les tests de charge doivent être effectués par rapport à une API factice (mock) — un service capable d'absorber de grandes quantités de requêtes et d'y répondre de manière appropriée, sans faire intervenir les Google Maps APIs. Vous pouvez ainsi tester la charge de votre application sans risquer d'être bloqué par les Google Maps APIs.

Consultez cet exemple d'API factice, implémentée sous forme de petite application Google App Engine : https://github.com/googlemaps/js-v2-samples/blob/gh-pages/mock_maps_apis/. Vous pouvez le transférer dans votre application App Engine (après en avoir enregistré une sur https://appengine.google.com/) et configurer cette application pour qu'elle envoie des requêtes à cette adresse plutôt qu'à maps.googleapis.com.

Les quotas App Engine (gratuits) par défaut sont généralement suffisants pour effectuer le test de charge de votre application, bien au-delà des quotas réservés aux services Web Maps API. Assurez-vous que votre application définit l'en-tête User-Agent approprié pour activer la compression des réponses. Étape 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.

Migrer vos API d'une licence gratuite vers une licence Google Maps APIs for Work

Autorisation des domaines

Pourquoi c'est important : Afin d'empêcher tout site non autorisé d'utiliser votre ID client, notre Google Maps JavaScript API exige que vous autorisiez tous les domaines auprès de notre équipe de support pour tous les sites qui utiliseront votre ID client. Si le site qui tente d'utiliser votre ID client ne correspond à aucune URL autorisée, votre site ne pourra pas utiliser les API avec cet ID client. Vous pouvez autoriser des domaines à tout moment. Aussi, veillez à autoriser ceux de tous vos sites avant le lancement.

Google Street View Image API et Google Static Maps API peuvent être utilisées en mode côté client ou côté serveur, avec génération de vues de page. Par conséquent, ces API exigent la signature de vos requêtes à l'aide de votre clé cryptographique et l'autorisation de tous les domaines utilisant ces API. Votre application pourra ainsi être correctement facturée (conformément à nos conditions de service), prise en charge et couverte par notre contrat de niveau de service.

Vous pouvez vérifier votre liste de domaines autorisés sur le Google Cloud Support Portal en cliquant sur le lien Maps: Manage Client ID dans le menu de navigation situé à gauche.

Pour les problèmes d'autorisation, nous vous recommandons de consulter l'article Résolution des problèmes d'autorisation pour les implémentations de Google Maps APIs for Work avant de renseigner une demande.

Intégration de votre ID client (par exemple, &client=gme-yourclientid)

Pourquoi c'est important : L'une des choses les plus importantes à faire pour votre application est d'inclure '&client=gme-yourclientid' dans vos requêtes. Votre ID client unique se trouve dans la lettre de bienvenue qui a été envoyée aux contacts principaux de votre organisation. L'ID client identifie vos requêtes en tant que requête Google Maps APIs for Work. Vous devez inclure votre ID client dans vos applications pour pouvoir profiter de toutes les fonctionnalités propres à Google Maps APIs for Work. Il est également nécessaire d'inclure votre ID client pour pouvoir recevoir une assistance technique et s'assurer que votre application est couverte par notre contrat de niveau de service

Utiliser la clé cryptographique (par ex. vNIXE0xscrmjlyV-12Nj_BvUPaw=) pour signer des requêtes de services Web

Pourquoi c'est important : Votre clé cryptographique privée est utilisée pour générer des signatures qui signalent à Google que vos requêtes proviennent d'une source fiable. Votre clé cryptographique se trouve dans la lettre de bienvenue qui a été envoyée aux contacts principaux de votre organisation. Parce que vous êtes un client Google Maps APIs for Work, nos services Web exigent que vous signiez vos requêtes à l'aide de votre clé cryptographique. Votre requête profite alors d'un niveau de sécurité supplémentaire qui protège davantage le quota associé à votre ID client.

Remarque : la clé cryptographique sert à générer des signatures. Elle ne doit pas être ajoutée à vos requêtes en tant que signature à proprement parler. Votre clé cryptographique ressemble au code secret de votre carte bancaire. Elle est utilisée comme moyen d'authentification pour accéder à votre compte et ne doit jamais être partagée ouvertement ni être visible par des sources non fiables. Les requêtes de services Web Google Maps APIs for Work qui ne sont pas correctement signées seront rejetées par nos serveurs. Il est donc essentiel que votre application signe correctement une requête avant le lancement (nb. La version 2 de Google Maps Geocoding API ne requiert actuellement aucune signature). Voir la documentation sur la signature des URL :

https://developers.google.com/maps/premium/previous-licenses/webservices/auth

Suivre l'utilisation des applications et le paramètre channel

Pourquoi c'est important : Un paramètre channel est un paramètre facultatif qui vous permet de suivre l'utilisation via votre ID client en attribuant un canal distinct à chacune de vos applications. Les paramètres channel n'ont pas besoin d'être enregistrés sous votre ID client. Ajoutez-les à votre requête d'API pour les voir apparaître dans les rapports d'utilisation du portail de support 1 ou 2 jours après l'implémentation. C'est à vous de décider où vos paramètres channel doivent être implémenté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 :

https://developers.google.com/maps/premium/previous-licenses/clientside/quota#reporting

Le paramètre channel doit utiliser le format suivant :

  • Il doit s'agir d'une chaîne alphanumérique ASCII.
  • Les caractères point (.), trait de soulignement (_) et tiret (-) sont autorisés.
  • Le paramètre channel n'est pas sensible à la casse ; les paramètres channel en majuscules, en minuscules ou mixtes sont transformés en minuscules. Par exemple, l'utilisation du paramètre channel CUSTOMER est combinée à celle du paramètre channel customer.

Vous pouvez implémenter jusqu'à 2 000 paramètres channel distincts par ID client.

Pour utiliser le paramètre channel, vous devez l'inclure 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.

Supprimer des paramètres obsolètes de vos requêtes d'API (par exemple, le paramètre '&key=ABQIAAAA…')

Pourquoi c'est important : Pour charger correctement Google Maps JavaScript API, vous devez inclure votre ID client. Vous devez également supprimer tous les paramètres key. Si votre requête comporte à la fois un ID client et une clé, elle échouera.

Consultez le guide Google Maps APIs for Work pour des informations détaillées sur le formatage des requêtes Google Maps APIs for Work par API : https://developers.google.com/maps/premium/previous-licenses/