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 APIs só com webhook excluem discretamente quem trabalha em lote
Um webhook faz sentido para um evento cujo momento você não consegue prever: um pagamento sendo compensado, o status de uma remessa mudando, algo acontecendo do lado do provedor ao qual seu sistema precisa reagir sempre que ocorrer. Faz muito menos sentido como a única forma de obter a resposta a uma pergunta que você fez diretamente e para a qual espera uma resposta direta, como resolver um endereço ou consultar um fuso horário. Exigir um endpoint de webhook só para receber o resultado de uma consulta síncrona empurra um trabalho real de infraestrutura para um cliente que talvez só queira executar um script, esperar uma resposta e seguir em frente.
Isso se torna um problema maior especificamente para casos de uso em lote e em massa. Um desenvolvedor que executa um script pontual para resolver uma lista de endereços de uma planilha não quer montar um receptor de webhooks, lidar com novas tentativas caso seu endpoint fique inacessível por um instante e relacionar os payloads de webhook recebidos com as requisições originais, tudo para obter respostas que poderiam ter voltado diretamente na resposta à chamada que as pediu. A entrega apenas por webhook para esse tipo de tarefa adiciona uma camada inteira de infraestrutura a uma tarefa que deveria ser uma única requisição e uma única resposta.
Tratamos as consultas, inclusive as em lote e em massa, como síncronas por padrão: você envia a requisição e recebe a resposta diretamente, contenha essa requisição um item ou mil. Nada no uso de um endpoint de lote exige montar um receptor público só para coletar os resultados. Um script, um cron job ou uma ferramenta de linha de comando pontual pode chamar o endpoint e usar a resposta imediatamente, da mesma forma que funcionaria uma consulta individual.
O design apenas com webhook costuma vir de uma arquitetura construída em torno de processamento assíncrono do lado do provedor, em que um grande job em lote realmente leva um tempo considerável para ser concluído internamente, e um webhook é de fato a forma mais natural de sinalizar a conclusão. Esse é um padrão legítimo para alguns tipos de processamento em grande escala ou com muitas filas. Torna-se um problema quando é a única opção oferecida, forçando todos os casos de uso, inclusive os que prefeririam apenas esperar um instante e receber uma resposta diretamente, a uma arquitetura projetada para um tipo de carga de trabalho diferente e mais lento.
Não somos contra a existência de webhooks como opção para trabalhos realmente longos ou assíncronos. Somos contra torná-los obrigatórios para tarefas que não precisam ser assíncronas. Um script que quer enviar mil consultas e receber mil respostas deve poder fazer exatamente isso, em uma chamada e uma resposta, sem antes construir uma infraestrutura para receber um callback de uma tarefa que uma requisição síncrona teria resolvido tão bem quanto, com muito menos código envolvido.