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 hosts de compatibilidade importam mais do que um novo SDK
Toda empresa de API quer que você instale o SDK dela. Um SDK prende. Depois que o seu código importa uma biblioteca cliente, chama os métodos dela e depende das estruturas de objeto dela, trocar de provedor significa reescrever o código que conversa com o provedor, e não apenas mudar uma URL. Essa dependência muitas vezes é o verdadeiro modelo de negócio por trás de um SDK gratuito e conveniente, alguém diga isso em voz alta ou não.
Nós seguimos outro caminho. O My Geocode tem 17 hosts compatíveis, cada um reproduzindo o formato de requisição e de resposta de outro provedor. Se o seu código já sabe chamar o endpoint de uma API de geocodificação conhecida e interpretar o JSON dela, você pode apontar exatamente esse código para o nosso host compatível e ele continua funcionando. Nenhum SDK para instalar, nenhum parsing de resposta para reescrever, nenhum modelo de objetos proprietário para aprender.
Isso parece um detalhe até você realmente tentar migrar um sistema em produção para fora de uma API. A URL do endpoint é a parte fácil. A parte difícil é cada lugar do seu código que acessa um nome de campo específico, trata um formato de erro específico ou pressupõe um estilo de paginação específico. Essas suposições se espalham pelo código ao longo dos anos, em lugares que ninguém lembra de verificar. Um host compatível elimina a necessidade de encontrá-las e corrigi-las, porque o formato não muda.
Um SDK, por outro lado, resolve um problema que você só vai enfrentar uma vez, conectar-se a uma API pela primeira vez, ao custo de um problema que você vai enfrentar durante toda a vida do produto: ficar preso às decisões de design desse SDK. Quando o SDK lança uma mudança incompatível, você absorve. Quando ele deixa de manter um binding de linguagem do qual você depende, você absorve isso também. Um host compatível em HTTP simples não tem nada dessa superfície. É apenas uma URL que retorna o formato de resposta que você já sabe ler.
Não somos contra SDKs em geral. Um wrapper leve que poupa você de escrever código repetitivo de HTTP é uma conveniência, não uma armadilha, desde que abandoná-lo depois não seja o mesmo projeto que trocar de provedor. A armadilha é quando os formatos do SDK se tornam os únicos formatos que o seu código entende, de modo que sair significa reescrever em vez de reconfigurar.
Construir 17 hosts compatíveis deu mais trabalho para nós do que construir um SDK teria dado. Cada host precisa reproduzir de perto o formato de resposta de outro provedor, campo por campo, para que as integrações existentes não percebam a diferença. Fizemos esse trabalho porque ele transfere o custo da troca do seu lado para o nosso. Você pode testar se os nossos dados, a nossa disponibilidade e os nossos preços funcionam para você sem antes pagar um custo de integração só para descobrir. Veja a lista completa de hosts compatíveis ou a documentação para saber como cada um corresponde ao original.
Um novo SDK pede que um desenvolvedor confie nas escolhas de engenharia de uma empresa durante toda a vida de um projeto. Um host compatível pede muito menos: mude uma URL base, talvez uma chave de API, e veja o que acontece. Essa é uma troca mais justa, e é o motivo pelo qual construímos hosts compatíveis antes de construir qualquer outra coisa.