Cada solicitud a My Geocode pasa por la misma infraestructura de servicio antes de que vuelva una respuesta, sin importar a qué endpoint vaya ni para qué host compatible esté preparada. Hace poco completamos una mejora de esa infraestructura compartida, y el resultado son tiempos de respuesta más rápidos en todos los ámbitos.
Se trata de un cambio en toda la plataforma y no de algo específico de un endpoint. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete y /v1/postcode funcionan sobre la misma infraestructura mejorada, al igual que los diecisiete hosts compatibles. Nada de los parámetros de solicitud, los campos de respuesta, los métodos de autenticación o los precios ha cambiado con esto. La mejora es totalmente interna y solo se nota en lo rápido que vuelve una respuesta.
En la mayoría de las integraciones, este tipo de mejora se percibe más que medirse con precisión: una sensación general de que las llamadas vuelven algo más rápido que antes. En las integraciones con un volumen importante, sobre todo los procesos por lotes que tratan muchos elementos en secuencia o cualquier tráfico de tipo autocompletado que se dispara repetidamente mientras el usuario escribe, el efecto se acumula a lo largo de muchas solicitudes y se nota más directamente. Un campo de autocompletado que envía una solicitud con cada pulsación de un término de búsqueda de ocho caracteres hace ocho llamadas en el tiempo que se tarda en escribirlo, y recortar incluso un poco de cada una cambia cómo se siente toda la interacción, de una forma que una consulta aislada no mostraría en absoluto.
Tratamos este tipo de trabajo de infraestructura como una responsabilidad continua y no como un proyecto puntual. Una API de geocodificación sobre la que la gente construye productos reales tiene que seguir rindiendo bien a medida que crece el uso, no solo el día de su lanzamiento, y eso significa revisar periódicamente la infraestructura de servicio en lugar de dejarla intacta indefinidamente. Esta mejora es un paso dentro de ese proceso continuo, no un destino final.
Como cada endpoint y cada host compatible funcionan sobre la misma infraestructura compartida, una mejora como esta solo tiene que hacerse una vez para beneficiarlos a todos, en lugar de repetirse endpoint por endpoint o host por host. Ese diseño compartido es también la razón por la que un cambio aquí nunca toca los formatos de solicitud, los campos de respuesta ni el motor de cuotas: todo eso vive en una capa completamente distinta.
Nada de la mecánica de cuotas o facturación cambia como resultado. Cada respuesta sigue incluyendo el mismo conjunto completo de encabezados de cuota, 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 y X-Quota-Reset, y las cuotas gratuitas, la tarifa del crédito prepago y el precio del paquete Unlimited no cambian.
Esa misma infraestructura compartida es sobre la que funciona también cada host compatible, así que una llamada con formato de TomTom y una llamada nativa a /v1/forward obtienen exactamente las mismas mejoras, y la mejora no es algo que haya que solicitar por host ni negociar por separado para una integración concreta.
Si tu integración es sensible al tiempo de respuesta, ya sea porque está de cara al usuario o porque procesa grandes volúmenes de solicitudes por lotes, deberías notar la diferencia sin necesidad de cambiar nada por tu parte. La documentación completa de cada endpoint sigue exactamente igual, disponible en /docs/.