À medida que o software continua a dominar o mundo, uma ênfase crescente em informações em tempo real, integrações perfeitas e automação impulsionou os webhooks para a vanguarda das arquiteturas de aplicativos modernas. Webhooks são agora um componente central na condução de fluxos de trabalho baseados em eventos em tempo real em todas as plataformas. Você pode ler o relatório completo aqui .
Agradecimentos especiais a Ojus Save from Zoom, Judy Vander Sluis da Intuit, Sharon Yelenik da Cloudinary, Sarah Edwards do Github e Kanad Gupta do ReadMe por colaborar conosco em nossas análises de documentação do webhook. Isso realmente nos ajudou a entender como as pessoas pensam sobre a documentação de suas APIs de webbooks e informou muitas de nossas decisões ao criar este relatório.
Neste relatório abrangente sobre o estado dos webhooks em 2023, analisamos mais de 100 dos principais provedores de API, examinando como eles adotaram e implementaram webhooks e analisando as diversas maneiras pelas quais essas implementações tomaram forma. A maioria dos principais provedores de API está de acordo com as melhores práticas? Além da mera adoção, como eles otimizaram, protegeram e enriqueceram suas ofertas de webhook para atender às necessidades dos desenvolvedores e das empresas atuais?
Reconhecendo que as verdades básicas muitas vezes surgem em casos de uso do mundo real, exploramos nossa própria base de clientes, compilando um cache intrigante de estatísticas que esclarecem a realidade das entregas de webhook. Com que frequência eles vacilam na natureza? De quantas tentativas essas mensagens geralmente precisam antes de chegarem com êxito aos aplicativos de destino? Estas estatísticas em primeira mão não só oferecem uma imagem clara das atuais taxas de sucesso de entrega, mas também demonstram o valor da implementação das melhores práticas.
Geralmente, descobrimos que a adoção do webhook é alta, de 83%. No entanto, a adoção da maioria das melhores práticas está atrasada.
As novas tentativas envolvem o reenvio de um webhook se uma tentativa falhar. Eles são cruciais para um serviço de webhook confiável porque problemas temporários de rede, tempos de inatividade do servidor ou outros erros transitórios podem impedir a entrega imediata de dados.
67% dos serviços ofereciam novas tentativas automáticas. A quantidade mais comum de novas tentativas oferecidas é 5, com a maioria oferecendo entre 3 e 10 tentativas. Cerca de 10% dos serviços afirmaram repetir mensagens com falha, mas não forneceram nenhuma informação sobre o agendamento de novas tentativas em si.
As novas tentativas do Webhook usam espera exponencial para lidar com falhas com eficiência, sem sobrecarregar o servidor receptor.
Ao aumentar progressivamente o tempo de espera entre novas tentativas, reduz o risco de agravar potenciais problemas do servidor e fornece uma abordagem mais adaptativa para lidar com falhas transitórias.
Concluindo, os webhooks estão sendo adotados pela maioria dos provedores de API, mas em sua maioria não conseguem implementar as melhores práticas. Mesmo aqueles que implementam a maioria das práticas recomendadas o fazem de maneiras diferentes. O espaço está tão fragmentado que os únicos fornecedores com implementações semelhantes foram aqueles que não implementaram quaisquer práticas recomendadas. Esperançosamente, este relatório irá desencadear um aumento na adoção de práticas recomendadas de webhook para ajudar a melhorar a experiência do desenvolvedor em torno de webhooks.
Ser capaz de repetir mensagens manualmente acelera a solução de problemas. É mais rápido acionar uma nova tentativa imediatamente, em vez de aguardar pela próxima tentativa automática. 12/83 provedores especificaram que novas tentativas poderiam ser acionadas manualmente. Esta foi a melhor prática menos adotada.
Para fins de teste, solução de problemas e depuração, um registro de tentativas de entrega de webhook é extremamente útil. Esta foi a segunda funcionalidade menos adotada, com 23% de adoção.
A organização dos eventos oferecidos aos consumidores de webhook em tipos de eventos permite que os usuários escolham para quais eventos desejam receber webhooks e reduz o número de mensagens desnecessárias e irrelevantes enviadas.
93% dos provedores ofereceram tipos de eventos. Esta é a prática recomendada mais amplamente adotada, que provavelmente decorre do fato de que os eventos são o valor central dos webhooks.
Oferecer aos usuários uma maneira de autenticar a origem e o conteúdo de uma mensagem de webhook é essencial para garantir que os dados não foram adulterados durante o trânsito e confirmar que se originam de uma fonte confiável
45 dos 83 provedores de webhook incluíram um carimbo de data/hora. O carimbo de data/hora é fundamental para evitar ataques de repetição.
Documentar bem um serviço de webhook pode economizar tempo dos usuários e evitar dores de cabeça.
Ter um código de amostra facilita a vida dos desenvolvedores. Embora apenas 43% oferecessem amostras de código, a inclusão de amostras de código estava fortemente correlacionada com o uso de assinaturas HMACSHA256.
A melhor documentação do webhook fornece orientação sobre como testar suas implementações de webhook. A orientação comum inclui como testar webhooks localmente (principalmente usando ngrok), listando várias ferramentas para ativar endpoints para receber mensagens de teste e fornecer a capacidade de enviar eventos de teste.
Há uma alta correlação entre ter amostras de código e fornecer orientação e ferramentas para testar webhooks.
No relatório completo, também apresentamos alguns dados internos do Svix para ver com que frequência as mensagens falham, com que frequência as novas tentativas são bem-sucedidas, os tempos médios de resposta e os tamanhos médios de carga útil das mensagens de webhook.
Para obter mais conteúdo como este, siga-nos no Twitter , Github ou RSS para obter as atualizações mais recentes do serviço webhook Svix ou participe da discussão em nossa comunidade Slack .