Modern applications work often reactive, based on a wide range of events. For that purpose, webhooks offer a simple and fast way to spin up processes, fired from these events.  Let’s have a look at what webhooks actually are.

Webhooks versus polling

When the concept of webhooks is explained, they are mostly compared with polling.

Polling involves the client that is interrogating the server API on regular time intervals, to know if there is new data to be processed.  The server side API performs each time a lookup and returns the result set, which is often empty.

Webhooks require the client to register first for specific events.  The client provides an URL that must be called in case a server side event occurs.  When an events occurs, the server looks into its subscription store and invokes every registered HTTP endpoint with the event payload.

Advantages

The “don’t call me, I call you” concept of webhooks, introduces the following advantages:

• More efficient: with polling, many API calls lead to no data exchange.  Webhooks are more resource-friendly, because there are only API calls when events occur.
• Faster: the speed of data exchange with polling depends on the polling interval of the client.  Webhooks invoke in near realtime the client, when an event occurs.
• No client side state: during polling, the client often needs to maintain state between two API calls (e.g. remember last modified datetime).  This requirement is not needed anymore, when applying webhooks.
• Extensibility: webhooks offer the ideal mechanism to provide extensibility for your (SaaS) application.  Consumers can perfectly extend the core application, by subscribing to the offered webhooks.

Disadvantages

Unfortunately, as with every design decision, there are also some downsides to using webhooks:

• Not standardized: because there’s no real standard, many different implementations for webhooks exist.  Hopefully, the CloudEvents standard will get wide industry adoption soon.
• Extra responsibilities: the webhook pattern is only successful when both client and server fulfil their responsibilities with regards to security, availability and reliability.
• Black-box: when using webhooks from external (SaaS) applications, you often don’t have any visibility in whether the webhooks have been fired or if they are facing internal problems.

Webhooks versus web sockets

Although both concepts have in common that they provide an alternative for polling, they are quite different.

Web sockets are mostly used in server to browser communication.  They required a long-lived connection and provide a two-way communication channel.

Webhooks are mostly used in server to server communication.  They initiate a short-lived connection when the event occurs and provide only a one-way communication.

Examples

There are many implementations of webhooks out there.  Here are some of them:

• GitHub: has state of the art support for webhooks.  You can choose the Content-Type, provide a secret for additional security and select multiple individual events.

• Teamleader: allows to subscribe to all events on their available CRM entities.  You can choose between JSON or XML format.

• Azure Monitor Alerts: Azure monitor alerts allow you to specify, next to the default email alerts, a webhook to be invoked when an alerts is fired.  It’s a good practice to provide the request URL of a Logic App, which can provide advanced notifications.

• Azure Event Grid: Azure Event Grid is a fully-managed intelligent event routing service that allows for uniform event consumption using a publish-subscribe model. Use Azure Event Grid to react to relevant events across both Azure and non-Azure services in near-real time fashion.

Watch this blog for more articles about webhooks!

Cheers,
Toon