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.
Por que preferimos responder com um erro a dar um palpite errado
Uma API que sempre retorna alguma coisa, mesmo para uma requisição que não consegue responder bem, parece mais capaz na superfície do que uma que às vezes retorna um erro claro. Essa impressão é enganosa. Uma resposta que chuta uma resposta em vez de admitir a incerteza não é mais útil. É mais perigosa, justamente porque parece exatamente uma resposta confiante e correta e não dá a quem chama nenhum sinal para verificar melhor antes de agir com base nela.
Preferimos retornar um erro claro, ou uma resposta que indique com clareza uma correspondência de baixa confiança ou parcial, a substituir silenciosamente por um palpite disfarçado de resposta normal. Isso importa mais na geocodificação direta, na geocodificação reversa e no preenchimento automático, exatamente os endpoints em que um endereço parcial ou ambíguo pode tentar um sistema a retornar a correspondência plausível mais próxima em vez de reconhecer que a entrada não foi resolvida de forma limpa. Uma correspondência plausível mais próxima apresentada como resultado normal é a forma mais provável de dados de localização ruins acabarem incorporados a uma remessa, a uma verificação de área de atendimento ou a um cadastro de cliente, porque nada na resposta indica que havia qualquer incerteza.
Isso também explica em parte por que somos deliberadamente cautelosos em divulgar um número de precisão específico e verificado para a geocodificação e o preenchimento automático, em vez de afirmar que esses recursos estão totalmente prontos e comprovados. Um sistema confiante o bastante para publicar um número de precisão específico precisa estar igualmente confiante sobre o que acontece com as entradas que esse número não cobre, e a resposta honesta, para qualquer sistema de geocodificação, inclui uma parcela de endereços que deveriam voltar como não resolvidos ou ambíguos, em vez de serem encaixados à força em uma resposta.
Uma resposta de erro tem um custo no momento: exige que a aplicação que faz a chamada trate um caso de falha em vez de sempre receber um objeto limpo, e pode parecer uma experiência de desenvolvimento pior na superfície, já que um palpite que por acaso está certo parece idêntico a uma resposta sem erro, e um palpite que por acaso está errado também, até que alguém mais adiante perceba. Esse é exatamente o problema. Um palpite e uma resposta correta são indistinguíveis de fora, e é justamente por isso que um sistema que não consegue diferenciá-los internamente não deveria disfarçar essa lacuna escolhendo um deles e apresentando-o como certo.
Achamos que essa preferência, uma falha clara em vez de um palpite confiante, deveria ser uma expectativa básica para qualquer API de dados, não apenas a nossa. Quem chama pode construir um tratamento de erros real em torno de um sistema que diz a verdade sobre o que não sabe. Ninguém consegue construir um tratamento de erros confiável em torno de um sistema que sempre responde, porque não há como distinguir as requisições que ele realmente acertou daquelas em que chutou silenciosamente e acabou caindo do lado errado.