Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Mettre en cache les résultats de géocodage sans fausser le calcul de votre quota
Géocoder la même adresse deux fois dans la semaine est un cas fréquent, et un cache en est la solution évidente. Ce qui piège souvent, c'est d'oublier qu'un succès de cache et un échec de cache se ressemblent parfaitement pour votre application, mais sont très différents pour votre quota.
Ce que l'on peut mettre en cache sans risque
Une adresse géocodée change rarement : mettre en cache le résultat complet d'une recherche directe ou inverse, avec l'entrée normalisée comme clé, est donc sûr pendant longtemps, des semaines ou des mois selon le taux de renouvellement de vos données d'adresses. Le résultat d'une recherche d'IP peut être mis en cache moins longtemps, car les plages sont parfois réattribuées. L'identifiant renvoyé par une recherche de fuseau horaire est stable, mais son utc_offset change avec l'heure d'été : mettez en cache l'identifiant et recalculez le décalage, plutôt que de conserver indéfiniment la réponse entière.
Servir depuis le cache ne touche pas au quota
Un succès de cache signifie que vous n'avez pas appelé l'API du tout pour cette requête : rien ne change donc dans X-Quota-Used ni dans votre solde de crédit. C'est tout l'intérêt du cache, mais cela signifie aussi qu'un succès de cache n'apparaîtra nulle part dans les en-têtes de quota, qui ne reflètent que les appels ayant réellement atteint l'API. N'essayez pas de rapprocher vos propres compteurs de requêtes des en-têtes de quota si vous ne suivez pas aussi séparément les succès de cache.
Exemple de clé de cache
cache_key = "forward:" + normalize("221B Baker Street, London")Normalisez en passant en minuscules, en supprimant les espaces en début et en fin, et en réduisant les espaces répétés avant le hachage, afin que des différences de mise en forme anodines dans l'entrée ne provoquent pas d'échecs de cache inutiles.
Estimer les volumes
Si la moitié de vos adresses entrantes sont des répétitions au sein d'une fenêtre de cache, votre nombre effectif de requêtes décomptées du quota gratuit et de votre éventuel crédit prépayé correspond à peu près à la moitié de votre volume brut d'adresses. C'est bon à savoir avant de décider s'il vous faut aller au-delà des 2 500 requêtes gratuites par jour incluses avec chaque clé, car le nombre réel d'appels qui atteignent l'API peut être bien inférieur à ce que suggère votre trafic brut.
Quand contourner le cache
Contournez le cache dans tous les cas où un résultat périmé serait carrément faux, par exemple pour revérifier une adresse qu'un client vient de corriger. Une recherche fraîche coûte une requête de toute façon : contourner le cache pour une correction précise est donc une assurance peu coûteuse contre la diffusion d'un résultat en cache que l'on sait erroné.
Bien mettre en cache consiste surtout à savoir quels champs sont stables et lesquels ne le sont pas, plutôt qu'à tout mettre en cache ou rien. Consultez la documentation du géocodage direct pour connaître les champs qui font de bonnes clés de cache.