Novo padrão de código aberto traz consistência aos webhooks

Ken Ruf passa muito tempo pensando e lendo sobre os desafios dos webhooks como parte de seu trabalho na Svix, uma empresa de “webhooks como serviço”. A maioria das reclamações vem de desenvolvedores que recebem webhooks, em vez de enviá-los, disse ele ao The New Stack.

“Muitas vezes víamos pessoas apenas reclamando dos webhooks e de como eles são ruins”, disse Ruf. “Ao observar grande parte da conversa, nossa hipótese era que o grande problema é a fragmentação. Tantas pessoas estão enviando de tantas maneiras diferentes que as pessoas que os recebem precisam basicamente refazer tudo sempre que têm uma nova fonte da qual desejam receber webhooks.”

Os webhooks diferem das APIs porque são usados ​​principalmente para dados em tempo real e para acionar fluxos de trabalho de automação. Os casos de uso incluem mensagens de chat, alertas de pagamento, atualizações de inventário, alterações de status de pedidos e eventos de criação de tarefas, como integração de clientes. Com webhooks, o aplicativo receptor assina eventos fornecendo um endpoint de URL para o aplicativo de origem.

“Webhooks atuam como retornos de chamada HTTP que permitem que os serviços notifiquem uns aos outros sobre eventos”, escreveu Vincent Le Goff, engenheiro de software sênior do provedor de gateway de API Kong. Le Goff faz parte do comitê diretor do novo padrão em nome de Kong. “Eles funcionam como uma ‘API reversa’, onde, em vez de um cliente iniciar solicitações a um serviço por meio de uma chamada de API, o serviço aciona proativamente um webhook para enviar atualizações ao cliente. Por exemplo, um serviço pode acionar webhooks para eventos como ‘um usuário pagou’ ou ‘tarefa concluída’”.

As APIs, por outro lado, são usadas com mais frequência para trocas de dados bidirecionais e tendem a envolver alguma latência de dados. A pesquisa da API é como Bart e Lisa Simpson na traseira de um carro – sempre perguntando “Já chegamos”, disse Ruf. Os webhooks são mais silenciosos – mais parecidos com Maggie, que aguarda a chegada sem toda a conversa. Outra analogia que ele ofereceu é que os webhooks são como ter uma campainha para alertá-lo sobre um hóspede – você não precisa verificar constantemente a porta da frente porque recebe uma mensagem quando o hóspede chega.

“Eles são muito flexíveis”, disse Ruf. “Na verdade, é sempre que você deseja acionar um fluxo de trabalho em seu sistema com base em um evento que acontece em outro produto ou aplicativo.”

Mas até o mês passado, os webhooks não tinham uma abordagem de design padrão. Para seu relatório State of Webhooks, a Svix analisou dez fatores em 100 documentos de fornecedores e descobriu que nenhum deles tinha exatamente a mesma implementação nesses dez fatores, disse Ruf. Isso é um problema para os desenvolvedores, especialmente à medida que os webhooks se tornam mais difundidos.

“O que acontece é que tenho a maior parte do meu código, mas tenho que alterá-lo porque eles não têm uma coisa entre dez, e porque todos eles são diferentes, … tenho que mudar um pouco novamente , repetidamente, em vez de apenas poder ter versões diferentes do mesmo endpoint para diferentes provedores”, disse ele. “Você literalmente precisa copiar a maior parte e depois mudar algumas coisas aqui e ali.”

Um exemplo do problema: há variação na frequência com que os webhooks repetem automaticamente mensagens com falha. O relatório State of Webhooks descobriu que 67% dos serviços ofereciam novas tentativas automáticas, com a quantidade mais comum de novas tentativas oferecidas sendo 5 – a maioria oferecida entre 3-10 novas tentativas. A melhor prática é um recuo exponencial, disse Ruf.

Essa falta de padrões levou Ruf e Tom Hacohen, fundador e CEO da Svix respectivamente, a decidirem criar um conjunto de padrões para webhooks. No ano passado, a dupla formou uma coalizão para fazer exatamente isso.

“O que realmente queríamos fazer era fazer com que as pessoas que enviam e recebem muitos webhooks em escala realmente adicionassem peso ao comitê, peso ao próprio padrão”, disse Ruf.

Além de Hacohen, o comitê diretor técnico inclui representantes de:

• Zapier, uma empresa de integração de aplicações web;
• Twilio, uma empresa de comunicação na web;
• Lob, uma empresa de sistemas de mala direta e cliente da Svix;
• Mux, uma empresa de streaming de vídeo;
• ngrok, uma plataforma de entrada unificada;
• Supabase, a alternativa de código aberto do Firebase; e
• Kong, uma malha de serviço e gateway de API, que possui algumas funcionalidades de webhook integradas, de acordo com Ruf.

No mês passado, o órgão emitiu a especificação Standard Webhooks de código aberto no GitHub, bem como lançou um site, Standard Webhooks, que oferece informações sobre como contribuir para o padrão, o órgão regulador e ferramentas de código aberto para verificar webhooks e simular um padrão. mensagem de webhooks.

Os padrões ajudarão os desenvolvedores que precisam configurar endpoints, disse ele. A adoção dos padrões tornará mais fácil a reutilização de código em vez de codificar tudo do zero, disse Ruf.

“Quando você está tentando criar um novo endpoint para um novo webhook a partir de outro aplicativo, você pode reutilizar muito mais código do webhook que já escreveu”, disse ele. “Neste momento, você basicamente precisa escrever tudo do zero. Portanto, esse é um benefício da padronização e uma coisa que estamos tentando realizar é tornar mais fácil para as pessoas adotarem webhooks de uma variedade de provedores diferentes.”

As normas especificam, entre outras coisas:

• Tamanho ideal de carga útil para webhooks (menor que 20kb);
• Metadados de webhook;
• Cabeçalhos de webhook; e
• Esquema de assinatura.

O padrão também define o que constitui um webhook de qualidade, estabelecendo as melhores práticas, acrescentou. Por exemplo, do jeito que está, se um webhook aciona ou não uma solicitação de autenticação depende do desenvolvedor individual.

“No momento, as pessoas estão em todos os lugares e é uma verdadeira dor de cabeça tentar receber webhooks de diferentes provedores, mas também queremos tornar o mais fácil possível para as pessoas oferecerem uma boa solução de webhook, porque isso é outra dor ponto”, disse ele.

O padrão não apenas descreve que a autenticação deve fazer parte de um processo de webhook, mas também oferece uma opinião sobre qual método de autenticação é melhor para webhooks: Assinaturas de código de autenticação de mensagem baseado em hash (HMAC).

Ruf não tem conhecimento de nenhum padrão concorrente específico para webhooks. Existe uma especificação chamada Cloud Events que descreve os dados do evento de uma maneira comum, mas aborda apenas brevemente os webhooks, disse ele.

“Lemos o padrão real deles e pensamos que há muito mais que precisa ser feito. Não é específico o suficiente”, disse ele, acrescentando que o objetivo é fornecer um padrão complementar que seja compatível com alguns dos trabalhos já realizados.

“Estamos apenas tentando facilitar a vida desses desenvolvedores quando eles precisam implementar pastas de trabalho, seja para sua empresa, para enviá-las a seus usuários ou se estão apenas tentando receber os webhooks de outros pessoas para acionar automações de fluxo de trabalho dentro de seus produtos”, disse Ruf. “Se conseguirmos que todos o adotem, isso tornará a vida de todos mais fácil.”

A postagem Novo padrão de código aberto traz consistência aos webhooks apareceu pela primeira vez em The New Stack.