O que lançamos este mês: geocodificação, IP, fuso horário e mais
Um resumo do trabalho recente em toda a API: novos hosts de compatibilidade, consultas de fuso horário e altitude mais rápidas, recursos no painel e mais visibilidade sobre a cota.
Tempos de resposta mais rápidos após uma atualização de infraestrutura
Toda requisição ao My Geocode passa pela mesma infraestrutura de atendimento antes que uma resposta volte, independentemente do endpoint que ela acessa ou do host compatível para o qual está formatada. Concluímos recentemente uma atualização dessa infraestrutura compartilhada, e o resultado são tempos de resposta mais rápidos em todos os casos.
Esta é uma mudança em toda a plataforma, e não algo específico de um endpoint. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete e /v1/postcode ficam todos sobre a mesma stack atualizada, assim como os dezessete hosts compatíveis. Nada nos parâmetros de requisição, nos campos de resposta, nos métodos de autenticação ou nos preços mudou com isso. A atualização acontece inteiramente nos bastidores e só é visível na rapidez com que uma resposta volta.
Na maioria das integrações, esse tipo de melhoria é mais sentido do que medido com precisão: uma sensação geral de que as chamadas voltam um pouco mais rápido do que antes. Em integrações com volume significativo, principalmente jobs em lote que processam muitos itens em sequência, ou qualquer coisa com tráfego do tipo preenchimento automático disparando repetidamente enquanto o usuário digita, o efeito se acumula ao longo de muitas requisições e fica mais fácil de notar diretamente. Um campo de preenchimento automático que envia uma requisição a cada tecla de um termo de busca de oito caracteres faz oito chamadas no tempo que se leva para digitá-lo, e reduzir mesmo um pouco o tempo de cada uma muda a sensação de toda a interação, de um jeito que uma consulta isolada nem mostraria.
Tratamos trabalhos de infraestrutura como este como uma responsabilidade contínua, e não como um projeto pontual. Uma API de geocodificação sobre a qual as pessoas constroem produtos reais precisa continuar com bom desempenho à medida que o uso cresce, não apenas no dia do lançamento, e isso significa revisitar a pilha de atendimento periodicamente em vez de deixá-la intocada indefinidamente. Esta atualização é uma etapa desse processo contínuo, não um destino final.
Como todos os endpoints e todos os hosts de compatibilidade passam pela mesma pilha compartilhada, uma atualização como esta só precisa acontecer uma vez para beneficiar todos eles, em vez de ser repetida endpoint por endpoint ou host por host. Esse design compartilhado também é o motivo pelo qual uma mudança aqui nunca afeta formatos de requisição, campos de resposta ou o mecanismo de cotas: eles ficam em uma camada totalmente diferente.
Nada na mecânica de cotas ou de cobrança muda com isso. Cada resposta continua trazendo o mesmo conjunto completo de cabeçalhos de cota, 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 e X-Quota-Reset, e as cotas gratuitas, a tarifa do crédito pré-pago e o preço do pacote Unlimited continuam os mesmos.
A mesma pilha compartilhada é também a base de todos os hosts de compatibilidade, então uma chamada no formato TomTom e uma chamada nativa para /v1/forward têm ganhos idênticos, e a melhoria não é algo que precise ser solicitado por host ou negociado separadamente para uma integração específica.
Se a sua integração é sensível ao tempo de resposta, seja por estar voltada ao usuário ou por processar grandes volumes de requisições em lote, você deve notar a diferença sem precisar mudar nada do seu lado. A documentação completa de cada endpoint continua exatamente como era, disponível em /docs/.