Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Un webhook es una petición HTTP que un servicio envía automáticamente a una dirección web registrada cuando ocurre un evento, como un cambio en un repositorio. Así, el sistema receptor puede reaccionar sin consultar continuamente la API. Para implementarlo con seguridad, verifica la autenticidad según el protocolo del proveedor, valida los datos y evita procesar dos veces la misma entrega.
Qué es un webhook
Un webhook es un mecanismo de comunicación entre sistemas basado en eventos. El sistema receptor registra una URL en el servicio emisor y especifica qué eventos le interesan. Cuando sucede uno de ellos, el emisor envía una petición HTTP con información sobre el evento a esa URL. GitHub describe los webhooks como suscripciones a eventos que generan entregas automáticas de datos al servidor.
Por ejemplo, si se registra un webhook para eventos de push en un repositorio, GitHub puede avisar al endpoint configurado cuando se suben cambios. El servidor receptor podría iniciar una compilación o un despliegue. Otros usos habituales incluyen enviar notificaciones, sincronizar información con un gestor de incidencias y registrar eventos.
Cómo funciona un webhook paso a paso
- El receptor prepara un endpoint. Es una URL accesible desde el servicio emisor, normalmente atendida por una aplicación o servidor.
- Registra la URL y elige los eventos. Se configura el webhook en el servicio que enviará las notificaciones. Conviene suscribirse solo a los eventos necesarios para reducir trabajo innecesario, como recomienda la guía de buenas prácticas de GitHub.
- Ocurre un evento. Cuando se produce uno de los eventos seleccionados, el emisor envía una petición HTTP con los datos asociados a la URL registrada.
- El endpoint comprueba y valida la solicitud. Antes de actuar, verifica su autenticidad con el método documentado por el proveedor, identifica el tipo de evento y valida el contenido.
- El receptor confirma la entrega y realiza el trabajo. Si la tarea tarda, puede encolar el trabajo y responder rápidamente; el procesamiento continúa en segundo plano.
Los plazos de respuesta dependen del proveedor. En el caso de GitHub, el endpoint debe responder con un estado HTTP 2XX en un máximo de 10 segundos; de lo contrario, la entrega se considera fallida. Ese límite no es una regla universal para todos los webhooks.
#1 Best Overall
Webhook frente a polling y llamadas a una API
Una API es una interfaz que permite a un programa solicitar o enviar datos. Un webhook suele usar HTTP y puede entregar datos relacionados con una API, pero cambia quién inicia cada comunicación: en el polling, el receptor pregunta periódicamente si hay novedades; en un webhook, el emisor avisa cuando ocurre un evento.
| Aspecto | Webhook | Polling |
|---|---|---|
| Quién inicia la comunicación | El servicio emisor envía una notificación cuando ocurre un evento. | El programa receptor consulta la API a intervalos. |
| Cuándo conviene | Para reaccionar de forma continua a eventos sin consultar una y otra vez. | Para una consulta única o esporádica, o cuando se supervisan pocos recursos y no se prevé escalar. |
| Actualización | Puede ser casi en tiempo real, según el servicio y la entrega. | Depende del intervalo entre consultas. |
| Trabajo y recursos | Puede reducir consultas y escalar mejor al supervisar muchos recursos. | Las consultas repetidas pueden consumir trabajo y recursos aunque no haya cambios. |
La elección depende de si necesitas conocer cambios continuamente, cuántos recursos supervisas y qué latencia aceptas. Según GitHub, los webhooks pueden reducir el esfuerzo de consultar repetidamente y ofrecer actualizaciones casi en tiempo real; para necesidades puntuales, llamar a la API puede ser más sencillo.
Rank #2
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
Cómo proteger un endpoint de webhook
- Usa HTTPS y conserva la verificación SSL. No desactives la validación de certificados para facilitar la conexión; GitHub recomienda mantenerla habilitada.
- Verifica las firmas con el método del proveedor. Los formatos, encabezados y datos firmados pueden variar. Sigue la documentación específica y, cuando el método lo requiera, verifica el cuerpo original de la solicitud. OWASP recomienda aplicar el formato de firma mantenido por el proveedor.
- Protege el secreto. Usa un valor aleatorio de alta entropía, guárdalo de forma segura y no lo pongas en la URL.
- Valida evento y contenido. Comprueba el tipo de evento y, si corresponde, la acción antes de procesarlo. Una firma válida ayuda a comprobar el origen, pero no sustituye la validación de los datos.
- Haz el procesamiento idempotente. Conserva identificadores de entrega o evento y evita repetir efectos, como crear un cargo, enviar un correo o actualizar dos veces el mismo estado. El identificador debe usarse de acuerdo con las garantías de autenticación del proveedor.
- Limita lo que guardas en los registros. No registres secretos, encabezados de autorización ni cuerpos completos que puedan contener datos personales. Conserva metadatos útiles para investigar errores.
Entregas repetidas, errores y recuperación
Una entrega puede repetirse, y las políticas de reintento no son iguales en todos los servicios. Diseña el receptor para reconocer entregas ya procesadas y revisa la documentación del proveedor para conocer sus reglas, herramientas de redelivery y formas de recuperar eventos perdidos. La guía de GitHub recomienda volver a entregar los eventos que se perdieron cuando el servidor vuelva a estar disponible.
No confundas un identificador de entrega con una prueba de autenticidad. Por ejemplo, GitHub permite usar el encabezado X-GitHub-Delivery para identificar entregas repetidas, pero OWASP advierte que ese encabezado no queda autenticado por la firma del cuerpo de GitHub. La verificación debe seguir el protocolo completo del proveedor; el identificador es útil para la deduplicación, no para sustituir la firma.
Rank #3
Qué revisar al elegir o configurar un proveedor
Antes de depender de un webhook, confirma cómo funciona la entrega en ese servicio. Las características no son uniformes: comprueba por separado el formato de firma, los identificadores de entrega, los reintentos y la redelivery, los límites de tiempo para responder, y las herramientas disponibles para probar y revisar eventos.
Quick Recap
Rank #4
- Brand: Wiley
- Set of 2 Volumes
- A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
