O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
O problema dos dados que só são precisos no dia do lançamento
É mais fácil se orgulhar de um conjunto de dados no dia em que ele é lançado. Ele foi verificado, limpo e validado com as fontes disponíveis na época, e o anúncio pode afirmar honestamente uma boa cobertura e precisão, porque naquele momento específico ele mereceu essa afirmação. O problema é que quase nada na geografia fica fixo por muito tempo. Limites administrativos mudam. As autoridades postais redesenham ou reemitem códigos. Os governos alteram as regras de horário de verão, às vezes com pouquíssimo aviso. Um conjunto de dados que era preciso no dia do lançamento e não recebeu manutenção ativa desde então já não é o mesmo conjunto de dados, mesmo que ainda seja divulgado com a mesma confiança.
O banco de dados de fusos horários da IANA é um exemplo útil de como isso é bem feito na prática: ele existe justamente porque as regras de fuso horário continuam mudando, e é atualizado à medida que essas mudanças acontecem, por pessoas cujo trabalho é acompanhar exatamente esse tipo de alteração. Uma API de geocodificação ou de localização que se baseia em uma fonte como essa e continua puxando atualizações dela está fazendo algo bem diferente de um provedor que montou um retrato único anos atrás e o serve desde então, com alguns remendos.
Achamos que essa distinção, manutenção contínua versus uma construção única, merece mais atenção do que costuma receber na forma como produtos de dados de localização são divulgados. Um anúncio de lançamento pode afirmar uma ampla cobertura de países, e isso será verdade. O que ele não pode prometer, por si só, é que a cobertura continue verdadeira dois anos depois, após mudanças de limites, reorganizações postais e alterações de regras de fuso horário que aconteceram discretamente nesse meio-tempo, sem nenhum motivo para o cliente saber que deveria verificar.
Isso é parte do motivo pelo qual tratamos os dados de fuso horário, altitude e IP como as partes do nosso produto que descrevemos de forma mais concreta, já que são áreas em que os dados de referência subjacentes, o tipo de fonte que o banco de dados da IANA representa para os fusos horários, recebem manutenção contínua por concepção, e não apenas pelo cronograma interno de atualizações de um provedor. É também por isso que tomamos cuidado para não exagerar ao apresentar a geocodificação direta, a geocodificação reversa e o preenchimento automático como totalmente prontos e com precisão verificada: os dados de endereço, em particular, têm uma enorme variação regional na qualidade da manutenção, e uma afirmação confiante sobre eles merece mais escrutínio do que a própria afirmação costuma provocar.
A idade de um conjunto de dados não é um defeito por si só. Um conjunto de dados de cinco anos atrás, bem mantido e atualizado, é mais confiável do que um novo que só será revisto de novo no próximo redesenho. O que importa é se o provedor trata a manutenção dos dados como uma obrigação contínua ou como um projeto único que terminou quando a página de marketing foi ao ar. A forma honesta de julgar isso não é o anúncio de lançamento. É o que o provedor faz, discretamente, nos anos seguintes.