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 custo silencioso da dependência de fornecedor
Ninguém contrata uma API planejando ficar preso a ela. A dependência de fornecedor não chega como uma cláusula de contrato que você pode negociar. Ela se acumula, uma conveniência de cada vez, até que o custo de trocar tenha crescido silenciosamente e ficado maior do que o custo do problema que fez você pensar em trocar.
Começa pequeno. Você instala o SDK do provedor porque ele economiza algumas horas escrevendo chamadas HTTP à mão. Você armazena o formato do objeto de resposta diretamente no seu banco de dados, em vez de mapeá-lo para o seu próprio esquema, porque esse mapeamento pareceu trabalho desnecessário na época. Você monta o tratamento de erros em torno dos códigos de status específicos do provedor, em vez de um padrão genérico. Cada uma dessas escolhas faz sentido por si só, no momento, sob a pressão normal de entrega. Nenhuma delas é feita pensando em dependência. Todas elas aumentam essa dependência.
Anos depois, o provedor aumenta os preços, ou tem uma falha durante um período movimentado, ou simplesmente deixa de ser a melhor opção para um recurso de que você agora precisa. Trocar deveria ser uma questão de escolher um novo fornecedor e atualizar um valor de configuração. Em vez disso, vira um projeto: reescrever a lógica de interpretação espalhada pelo código, refazer o tratamento de erros, readaptar todas as ferramentas internas que cresceram em torno do formato antigo. O custo da troca nunca foi cobrado em uma fatura. Ele foi pago antecipadamente, em pequenas decisões de integração que ninguém sinalizou como arriscadas na época.
Criamos os hosts de compatibilidade justamente contra esse padrão. Se a sua integração já fala o formato de requisição e de resposta de outro provedor, apontá-la para um dos nossos 17 hosts de compatibilidade não exige que você tenha planejado a portabilidade com antecedência. Você ganha a opção de sair sem ter tido a previsão de construir pensando em sair. Essa é uma diferença significativa em relação à maioria dos conselhos contra a dependência de fornecedor, que costumam dizer "construa sobre uma camada de abstração desde o primeiro dia", um bom conselho que quase ninguém realmente segue sob a pressão de prazos.
A autenticação é um exemplo menor do mesmo princípio. Alguns provedores empurram você para um método de autenticação específico, amarrando a sua integração a um determinado padrão de cliente. Aceitamos uma chave como cabeçalho X-API-Key, como cabeçalho Authorization Bearer, via HTTP Basic auth ou como parâmetro de consulta, em todos os hosts, sem custo extra para nenhum deles. Qualquer que seja o padrão que o seu código já usa para outras APIs, o nosso provavelmente se encaixa nele, então você não precisa reescrever a sua camada de autenticação só para nos experimentar.
O motivo honesto pelo qual a dependência de fornecedor persiste neste setor é que ela funciona, comercialmente. Um cliente que sairia só por causa do preço muitas vezes fica porque sair significa reescrever tudo. Achamos que essa é uma troca ruim sobre a qual construir um negócio, porque ela conquista os clientes que já estão insatisfeitos, e não os que estão realmente satisfeitos. Se sair continuar barato, os clientes que ficam estão ficando porque o produto ainda vale a pena, e não porque a porta de saída foi silenciosamente emparedada em algum momento lá no segundo ano.