Limites d'utilisation des services Web Google Maps APIs

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.

Décembre 2011

L'utilisation des services Web Google Maps APIs est soumise à des limites spécifiques quant au nombre de requêtes par tranche de 24 heures. Les requêtes envoyées au-delà de ces limites génèrent un message d'erreur.

Les limites d'utilisation sont décrites dans les FAQ Google Maps APIs for Work sur les licences précédentes.

Cet article est destiné aux clients Google Maps APIs for Work qui ont atteint ces limites et souhaitent optimiser leurs applications pour une utilisation plus efficace des services Web.

Aspects fondamentaux

Google Maps propose des services Web qui servent d'interface pour obtenir des données Google Maps à utiliser dans vos applications. Ces services ne peuvent être utilisés que conjointement avec une carte Google. Il est interdit d'utiliser des données issues de ces services sans les afficher sur une carte Google. Pour des informations détaillées, consultez les Restrictions liées aux licences des Conditions de service de Google Maps APIs.

Les quotas qui limitent l'utilisation des services Web Google Maps APIs sont de deux types : quotas à long terme (par jour) et quotas à court terme (taux de requête). Si vous dépassez les limites d'utilisation ou exercez toute autre utilisation abusive du service Web, celui-ci renvoie un message d'erreur spécifique. Si vous continuez de dépasser les limites, votre accès au service Web peut être bloqué. Il est également possible de recevoir des réponses de type « 403 Forbidden ».

Remarque : différentes limites s'appliquent aux API côté client. Dans le cas de Maps JavaScript API, chaque session de carte est limitée par un taux afin d'assurer la répartition des requêtes entre les utilisateurs. Ainsi, l'utilisation basée sur navigateur est évolutive lorsque le nombre d'utilisateurs augmente. Pour faire votre choix entre les services Web côté serveur et leurs équivalents côté client, voir le document Stratégies de géocodage.

Problèmes

Vous pouvez dépasser les limites d'utilisation des services Web Google Maps APIs de plusieurs façons :

  • Vous envoyez un trop grand nombre de requêtes par jour.
  • Vous envoyez les requêtes trop rapidement, c'est-à-dire un trop grand nombre de requêtes par seconde.
  • Vous utilisez le service Web de manière abusive, par exemple en envoyant des requêtes trop rapidement pendant trop longtemps.
  • Vous dépassez d'autres limites d'utilisation (points par requête dans Google Maps Elevation API, par exemple).

Dépassement des limites d'utilisation

Si vous dépassez les limites d'utilisation, vous obtenez le code de statut OVER_QUERY_LIMIT en guise de réponse.

Cela indique que le service Web cesse de fournir des réponses normales et renvoie désormais uniquement le code de statut OVER_QUERY_LIMIT jusqu'à ce qu'un niveau d'utilisation supérieur soit à nouveau autorisé. Cela peut se produire :

  • En quelques secondes si l'erreur a été générée parce que l'application a envoyé un trop grand nombre de requêtes par seconde.
  • Dans un délai de 24 heures si l'erreur a été générée parce que l'application a envoyé un trop grand nombre de requêtes par jour. Les quotas journaliers sont réinitialisés à minuit, heure du Pacifique.

Cet enregistrement d'écran explique pas à pas comment réguler les requêtes et gérer les erreurs de manière adéquate. Il est applicable à tous les services Web.

Lorsqu'elle reçoit une réponse avec le code de statut OVER_QUERY_LIMIT, votre application doit identifier la limite d'utilisation qui a été dépassée. Pour ce faire, vous pouvez renvoyer la même requête après une pause de 2 secondes. Si le code de statut est encore OVER_QUERY_LIMIT, votre application envoie trop de requêtes par jour. Sinon, elle envoie trop de requêtes par seconde.

Voici un exemple d'implémentation dans Python :

url = "MAPS_API_WEBSERVICE_URL"
attempts = 0
success = False

while success != True and attempts < 3:
  raw_result = urllib.urlopen(url).read()
  attempts += 1
  # The GetStatus function parses the answer and returns the status code
  # This function is out of the scope of this example (you can use a SDK).
  status = GetStatus(raw_result)
  if status == "OVER_QUERY_LIMIT":
    time.sleep(2)
    # retry
    continue
  success = True

if attempts == 3:
  # send an alert as this means that the daily limit has been reached
  print "Daily limit has been reached"

Remarque : Il est également possible de recevoir l'erreur OVER_QUERY_LIMIT :

Avant d'envoyer des requêtes, les applications doivent s'assurer que ces limites sont respectées.

Réponse HTTP 403

Les requêtes envoyées aux services Web peuvent également générer une erreur HTTP 403 (Forbidden). Dans la plupart des cas, elle est due à une signature URL incorrecte. Pour le vérifier, supprimez les paramètres client et signature et réessayez :

  • Si la réponse est HTTP 200 (OK), le problème réside dans la signature.
    Cela n'a rien à voir avec les limites d'utilisation. Pour plus de détails, voir Résolution des problèmes d'authentification dans le chapitre Services Web de la documentation Google Maps APIs for Work.
  • Si la réponse est encore une erreur HTTP 403 (Forbidden), il est possible que le problème ne soit pas lié à la signature, mais aux limites d'utilisation.
    En général, cela signifie que votre accès au service Web a été bloqué parce que votre application a dépassé les limites d'utilisation pendant trop longtemps ou a abusé du service Web d'une autre manière. Si ce problème se produit, accédez au Google Cloud Support Portal. Les coordonnées du service d'assistance sont également disponibles sur la page Support et ressources.

La signature URL est requise pour toute requête de service Web. Les requêtes sont également rejetées et génèrent une erreur HTTP 403 (Forbidden) si elles comprennent le paramètre client, mais pas le paramètre signature, ou vice versa.

Solutions

Il est possible de résoudre les problèmes ci-dessus en combinant deux approches :

  1. Réduire l'utilisation en optimisant les applications pour utiliser les services Web plus efficacement.
  2. Accroître les limites d'utilisation, dans la mesure du possible, en achetant une marge supplémentaire pour votre licence Google Maps APIs for Work.

Cet article s'intéresse spécifiquement aux méthodes d'optimisation des applications pour une utilisation plus efficace des services Web.

Contrôles d'intégrité

Avant de chercher à utiliser plus efficacement un service Web, prenez le temps de vérifier que le service et la licence employés sont corrects.

Valider votre cas d'utilisation

Les services Web Google Maps APIs sont spécialement adaptés aux applications qui ne disposent pas de données saisies en temps réel par l'utilisateur final ou pour lesquelles aucun navigateur Web n'est disponible. Cela se produit généralement lorsque vous obtenez un ensemble de données indépendant des informations saisies par l'utilisateur. C'est le cas, par exemple, si vous utilisez une base de données contenant un ensemble fixe d'adresses à géocoder, telles que des propriétés mises en vente sur un site Web immobilier, ou encore des adresses de magasins.

Lorsque vous utilisez les services Web Google Maps APIs, les quotas (journalier et par seconde) associés à votre ID client tiennent compte de toutes les requêtes. Ces quotas s'appliquent à toutes les requêtes envoyées avec un ID client donné, quel que soit le nombre d'adresses IP utilisées.

Lorsque les services Maps JavaScript API côté client sont utilisés dans le navigateur, chaque session de carte est limitée par un taux. En d'autres termes, les requêtes sont réparties entre tous vos utilisateurs et augmentent avec le nombre d'utilisateurs. Les API côté client sont donc toujours utilisées de préférence, dans la mesure du possible. Elles sont idéales si vous collectez des adresses auprès des utilisateurs pour les géocoder en temps réel, par exemple lors d'une recherche de magasins à proximité de l'adresse du domicile de l'utilisateur.

Pour des informations plus détaillées, voir le document Stratégies de géocodage. Bien que spécifiques au géocodage, les recommandations fournies dans ce document s'appliquent à tous les services Web. Le document indique dans quels cas il est préférable d'utiliser des services Web côté serveur et dans quels cas utiliser plutôt leurs équivalents côté client.

Utiliser une licence Google Maps APIs for Work

Si vous possédez une licence Google Maps APIs for Work, assurez-vous que vos requêtes spécifient correctement votre ID client.

Les clients Google Maps APIs for Work disposent de limites d'utilisation pour les services Web Google Maps APIs plus élevées que les utilisateurs des API gratuites. Pour en bénéficier, vos applications doivent définir le paramètre client correctement, comme décrit dans le chapitre Services Web de ce guide.

Si une application n'utilise pas correctement un ID client Google Maps APIs for Work, elle n'est pas considérée comme une application commerciale, ne bénéficie pas des fonctionnalités et marges de limites d'utilisation réservées aux applications commerciales, ni du support technique, n'est pas couverte par le SLA Google Maps APIs for Work et est soumise aux Restrictions liées aux licences des Conditions de service de Google Maps APIs standard.

Comment optimiser vos applications

Les optimisations à mettre en œuvre pour utiliser plus efficacement les services Web se résument à deux objectifs principaux : réduire l'utilisation en envoyant des requêtes seulement lorsqu'elles sont absolument nécessaires et répartir uniformément l'utilisation pour éviter qu'elle ne dépasse les limites.

Mettre en cache les résultats

La section 10.5.d des Conditions de service de Google Maps APIs souligne que vous pouvez stocker une quantité limitée de contenu dans le but d'améliorer les performances de votre implémentation de Google Maps APIs en raison de la latence du réseau (et non pour empêcher Google d'effectuer un suivi précis de l'utilisation), et uniquement si ce stockage est temporaire (et en aucun cas supérieur à 30 jours calendaires) et sécurisé, ne manipule ni ne regroupe aucune partie du Contenu ou du Service, et ne modifie aucune mention, de quelque façon que ce soit.

Cela signifie que vous pouvez temporairement mettre en cache des réponses de service Web pour éviter d'envoyer des requêtes dupliquées sur une courte période. Les réponses provenant des services Web incluent toujours l'en-tête HTTP Cache-Control pour indiquer la durée maximale de la mise en cache du résultat, actuellement 24 heures :

Cache-Control: public, max-age=86400

Cet en-tête doit toujours être respecté. La mise en cache peut être implémentée à l'aide des proxies Web (qui font cela de manière automatique) ou par le biais de votre implémentation. Notez que certaines bibliothèques client HTTP mettent aussi en cache les réponses HTTP.

Pour accroître le taux de succès de la mise en cache, veillez à normaliser les coordonnées LatLng en les arrondissant à 6 décimales, ce qui offre une précision d'environ 11 centimètres au niveau de l'équateur. Si le nombre de décimales augmente, les résultats des services Web ne changent pas, mais le taux de succès de la mise en cache diminue.

Réguler les requêtes

Les applications doivent réguler les requêtes pour éviter de dépasser les limites d'utilisation, en tenant compte du fait que celles-ci s'appliquent à chaque ID client, indépendamment du nombre d'adresses IP utilisées pour envoyer les requêtes.

Pour réguler les requêtes, vous pouvez les placer dans une file d'attente qui consigne l'heure à laquelle elles sont envoyées. Si la limite de taux est de 10 QPS (requêtes par seconde), à l'envoi de la onzième requête, votre application doit vérifier l'horodatage de la première requête et attendre qu'une seconde complète soit écoulée. La même règle s'applique aux limites journalières.

Même si la régulation est mise en œuvre correctement, les applications doivent prendre garde aux réponses contenant le code de statut OVER_QUERY_LIMIT. En cas de réception d'une telle réponse, utilisez le mécanisme expliqué dans la section Dépassement des limites d'utilisation ci-dessus (nouvelle tentative après une pause) pour identifier la limite qui a été dépassée.

Gérer les accumulations de requêtes

Si la régulation est correctement mise en œuvre, les requêtes envoyées aux services Web ne dépassent pas les limites d'utilisation. Toutefois, les applications peuvent recevoir des données qui dépassent les limites d'utilisation des services Web, que ce soit en raison du volume des données ou de la vitesse de leur transfert. Dans ce cas, les files d'attente de régulation peuvent gonfler considérablement, jusqu'à créer une accumulation de requêtes en attente.

Vos applications peuvent atteindre les limites d'utilisation journalières lorsqu'elles traitent de gros volumes de requêtes accumulés. Si la régulation est correctement mise en œuvre pour les limites journalières, les applications cessent d'envoyer des requêtes. Sinon, les nouvelles requêtes envoyées génèrent des réponses avec le code de statut OVER_QUERY_LIMIT. Dans les deux cas, l'accumulation de requêtes en attente devrait diminuer.

Si le volume moyen de requêtes par jour ou par semaine reste au-dessous des limites d'utilisation, vos applications devraient être en mesure de résoudre l'accumulation de requêtes pendant les périodes où l'afflux de données est réduit. Sinon, vous devrez peut-être augmenter la marge journalière de votre licence Google Maps APIs for Work (voir section suivante).

Quand l'optimisation n'est pas suffisante

Si vous avez mis en œuvre toutes les optimisations décrites ci-dessus et que l'accumulation de requêtes dans la file d'attente augmente constamment, quotidiennement ou à tout moment de la journée, vous devrez peut-être accroître les limites d'utilisation journalières ou par seconde associées à votre licence Google Maps APIs for Work. Dans ce cas, contactez votre gestionnaire de compte Google Maps APIs for Work pour discuter des options disponibles.