Last week during retro with my team, one team member told us that he was not fully aware about how webhooks worked or which value they brought to the table. So I decided to write a little bit about them.
According to Wikipedia, Webhooks are "user-defined HTTP callbacks". They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.
In simpler terms, webhooks are the counterpart to an API. In the sense that they provide you information by pushing, relieving you of the responsibility of pulling.
Let's take a look at the following schema:
In this example there is an API that can be called with a movie_id, the response contains some meta data about the movie itself and also the places where it is currently streaming at. If you were really big on that movie and wanted to know as soon as it shows up in whichever streaming service, you'd need to be calling the API constantly.
Sometimes you might even forget about it. Maybe you decide to create a script to fetch that information for you. For this one case, that might be plausible, but now picture needing that same information for thousands and thousands of movies. The script would probably get rate limited. You would have wasted compute and networking resources in vain, because there might not be a change at all. Not to mention API fees if the API has some sort of pricing attached to it.
Now let's look at this same problem, but supposing there is a Webhooks API as well as the regular API:
Notice that we are providing an endpoint_url that is a specific endpoint within our domain that will handle whatever payload the movie service decides to send. We are asking to be subscribed to changes on the streaming_on field for a specifc movie_id.
Now, whenever there is a change to the streaming_on field we will get a payload to the provided endpoint_url. That url will be an endpoint of ours that has the business logic to handle whichever information the payload provides.
So that's webhooks in a nutshell. The business applications are endless, since there are lots of different events that one might be interested on monitoring for different purposes.
If you want to play around here are some well documented Webhooks APIs:
Another handy link is https://webhook.site . It provides you with a disposable endpoint_url for you to use when subscribing to webhooks. There you can see payloads as they are posted to you from which ever webhooks api you subscribed, it also has a 500 request log.
I hope you found this basic introduction interesting and insightful, thanks for reading !
For more updates make sure to follow me on twitter @arielpozo
Picture by Joetography on Pexels