Chaque requête adressée à My Geocode passe par la même infrastructure de service avant qu'une réponse ne revienne, quel que soit l'endpoint visé ou l'hôte compatible dont elle adopte le format. Nous avons récemment achevé une mise à niveau de cette infrastructure partagée, et le résultat est une réduction générale des temps de réponse.
Il s'agit d'un changement à l'échelle de la plateforme, et non d'une modification propre à un endpoint. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete et /v1/postcode reposent tous sur la même pile mise à niveau, tout comme les dix-sept hôtes compatibles. Rien n'a changé dans les paramètres de requête, les champs de réponse, les méthodes d'authentification ou les tarifs à cette occasion. La mise à niveau se fait entièrement en coulisses et ne se voit qu'à la rapidité avec laquelle une réponse revient.
Pour la plupart des intégrations, ce type d'amélioration se ressent plus qu'il ne se mesure précisément : une impression générale que les appels reviennent un peu plus vite qu'avant. Pour les intégrations qui traitent un volume important, en particulier les tâches par lots qui traitent de nombreux éléments à la suite, ou tout trafic de type saisie semi-automatique qui se déclenche à répétition pendant qu'un utilisateur tape, l'effet se cumule sur de nombreuses requêtes et devient plus facile à constater directement. Un champ de saisie semi-automatique qui envoie une requête à chaque frappe d'un terme de recherche de huit caractères effectue huit appels le temps de le taper, et gagner ne serait-ce qu'un peu de temps sur chacun change la perception de toute l'interaction, d'une façon qu'une recherche isolée ne montrerait pas du tout.
Nous considérons ce type de travail d'infrastructure comme une responsabilité permanente plutôt que comme un projet ponctuel. Une API de géocodage sur laquelle des gens bâtissent de vrais produits doit continuer à bien fonctionner à mesure que l'usage augmente, pas seulement le jour de son lancement, ce qui implique de revoir régulièrement la pile de service plutôt que de la laisser indéfiniment en l'état. Cette mise à niveau est une étape de ce processus continu, pas une destination finale.
Comme chaque endpoint et chaque hôte compatible passent par la même pile partagée, une mise à niveau comme celle-ci ne doit être faite qu'une seule fois pour profiter à tous, au lieu d'être répétée endpoint par endpoint ou hôte par hôte. Cette conception partagée explique aussi pourquoi une modification à ce niveau ne touche jamais aux formats de requête, aux champs de réponse ni au moteur de quotas : ceux-ci se situent à une couche entièrement différente.
Aucun mécanisme de quota ou de facturation ne change pour autant. Chaque réponse contient toujours le même ensemble complet d'en-têtes de quota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit et X-Quota-Reset, et les quotas gratuits, le tarif du crédit prépayé et le prix du forfait Unlimited restent tous inchangés.
Tous les hôtes compatibles reposent eux aussi sur cette même pile partagée : un appel au format TomTom et un appel natif à /v1/forward bénéficient donc des mêmes gains, et l'amélioration n'a pas à être demandée hôte par hôte ni négociée séparément pour une intégration particulière.
Si votre intégration est sensible au temps de réponse, parce qu'elle est exposée aux utilisateurs ou parce qu'elle traite de gros volumes de requêtes par lots, vous devriez constater une différence sans rien changer de votre côté. La documentation complète de chaque endpoint reste exactement la même et se trouve sur /docs/.