A medida que el software continúa devorando el mundo, un énfasis cada vez mayor en la información en tiempo real, las integraciones perfectas y la automatización ha impulsado los webhooks a la vanguardia de las arquitecturas de aplicaciones modernas. Los webhooks son ahora un componente central para impulsar flujos de trabajo basados en eventos en tiempo real en todas las plataformas. Puedes leer el informe completo aquí .
Un agradecimiento especial a Ojus Save de Zoom, Judy Vander Sluis de Intuit, Sharon Yelenik de Cloudinary, Sarah Edwards de Github y Kanad Gupta de ReadMe por colaborar con nosotros en nuestras revisiones de documentación de webhooks. Realmente nos ayudó a comprender cómo piensa la gente acerca de documentar las API de sus libros web y nos informó muchas de nuestras decisiones al crear este informe.
En este informe completo sobre el estado de los webhooks en 2023, analizamos más de 100 de los principales proveedores de API, examinamos cómo adoptaron e implementaron webhooks y analizamos las diversas formas en que han tomado forma estas implementaciones. ¿La mayoría de los principales proveedores de API están de acuerdo con las mejores prácticas? Más allá de la mera adopción, ¿cómo han optimizado, asegurado y enriquecido sus ofertas de webhooks para satisfacer las necesidades de los desarrolladores y empresas actuales?
Reconociendo que las verdades fundamentales a menudo surgen en casos de uso del mundo real, hemos recurrido a nuestra propia base de clientes, compilando un intrigante caché de estadísticas que arrojan luz sobre las realidades de las entregas de webhooks. ¿Con qué frecuencia fallan en la naturaleza? ¿Cuántos reintentos necesitan generalmente estos mensajes antes de llegar exitosamente a sus aplicaciones de destino? Estas estadísticas de primera mano no sólo ofrecen una imagen clara de las tasas actuales de éxito en la entrega, sino que también demuestran el valor de implementar las mejores prácticas.
En general, descubrimos que la adopción de webhooks es alta: 83 %. Sin embargo, la adopción de la mayoría de las mejores prácticas está retrasada.
Los reintentos implican volver a enviar un webhook si falla el intento. Son cruciales para un servicio de webhook confiable porque los problemas temporales de la red, los tiempos de inactividad del servidor u otros errores transitorios pueden impedir la entrega inmediata de datos.
El 67% de los servicios ofrecían reintentos automáticos. La cantidad más común de reintentos ofrecidos es 5 y la mayoría ofrece entre 3 y 10 reintentos. Alrededor del 10% de los servicios afirmaron que habían reintentado mensajes fallidos, pero no proporcionaron ninguna información sobre el calendario de reintentos en sí.
Los reintentos de Webhook utilizan un retroceso exponencial para manejar fallas de manera eficiente sin sobrecargar al servidor receptor.
Al aumentar progresivamente el tiempo de espera entre reintentos, se reduce el riesgo de exacerbar posibles problemas del servidor y proporciona un enfoque más adaptable para manejar fallas transitorias.
En conclusión, la mayoría de los proveedores de API están adoptando webhooks, pero en su mayoría no implementan las mejores prácticas. Incluso aquellos que implementan la mayoría de las mejores prácticas lo hacen de diferentes maneras. El espacio está tan fragmentado que los únicos proveedores con implementaciones similares fueron aquellos que no implementaron las mejores prácticas en absoluto. Con suerte, este informe provocará un aumento en la adopción de las mejores prácticas de webhooks para ayudar a mejorar la experiencia de los desarrolladores en torno a los webhooks.
Poder reintentar mensajes manualmente acelera la resolución de problemas. Es más rápido activar un reintento inmediatamente en lugar de esperar el siguiente reintento automático. 12/83 proveedores especificaron que los reintentos podrían activarse manualmente. Esta fue la mejor práctica menos adoptada.
Para fines de prueba, solución de problemas y depuración, un registro de los intentos de entrega de webhooks es extremadamente útil. Esta fue la segunda funcionalidad menos adoptada con un 23% de adopción.
Organizar los eventos ofrecidos a los consumidores de webhooks en tipos de eventos permite a los usuarios elegir para qué eventos desean recibir webhooks y reduce la cantidad de mensajes innecesarios e irrelevantes que se envían.
El 93% de los proveedores ofrecieron tipos de eventos. Esta es la mejor práctica más adoptada y probablemente se debe al hecho de que los eventos son el valor central de los webhooks.
Ofrecer a los usuarios una forma de autenticar el origen y el contenido de un mensaje de webhook es esencial para garantizar que los datos no hayan sido manipulados durante el tránsito y confirme que provienen de una fuente confiable.
45 de 83 proveedores de webhooks incluyeron una marca de tiempo. La marca de tiempo es fundamental para evitar ataques de repetición.
Documentar bien un servicio de webhook puede ahorrarles tiempo a los usuarios y evitarles dolores de cabeza.
Tener un código de muestra facilita la vida de los desarrolladores. Si bien solo el 43 % ofrecía ejemplos de código, la inclusión de ejemplos de código se correlacionaba en gran medida con el uso de firmas HMACSHA256.
La mejor documentación de webhooks brinda orientación sobre cómo probar sus implementaciones de webhooks. La guía común incluye cómo probar webhooks localmente (principalmente usando ngrok), enumerar varias herramientas para activar puntos finales para recibir mensajes de prueba y brindar la capacidad de enviar eventos de prueba.
Existe una alta correlación entre tener ejemplos de código y proporcionar orientación y herramientas para probar webhooks.
En el informe completo, también presentamos algunos datos internos de Svix para ver con qué frecuencia fallan los mensajes, con qué frecuencia los reintentos tienen éxito, los tiempos de respuesta promedio y los tamaños promedio de carga útil de los mensajes de webhook.
Para obtener más contenido como este, asegúrese de seguirnos en Twitter , Github o RSS para conocer las últimas actualizaciones del servicio webhook Svix , o únase a la discusión en nuestra comunidad Slack .