In this post we look at the difference between APIs and Webhooks. We will also take a deeper look into APIs. Spoiler alert: a webhook is just a reverse API.
API VS Webhook
APIs are everywhere, and it is the word on everyone’s lips? From web development all the way through to enterprise data provisioning, everyone wants a piece of the API Pie. But what is this web hook thing now? Well, its simpler than you might think.
Let’s get down to the difference between API and Webhooks:
A web hook is a reverse API. Think of it like this, an API will provide a response to a request. A web hook will provide a response to all those who have subscribed to it when x thing happens.
Why does this exist? In my own words: To get rid of polling. Let us put it in context of a 3-year-old child that is eagerly waiting a batch of cookies to be baked. They desperately want to partake in these delicious golden brown chocolate chip cookies (oh and the chocolate chips are Nutella…). An API will be the 3-year-old child that constantly asks “are they done yet? Are they done now? How about now?”.
A webhook is when you tell the child, here is the TV, watch this show for now and I will bring you a cookie when they are ready ok.
Now that we answered the question that I click baited you with, let us take a quick look at each of these concepts individually:
What are APIs?
An API (Application Programming Interface) is any piece of code that has a specific purpose. We commonly refer to APIs in the context of webservices, meaning a piece of code, or a service, which does a specific thing when you call it. That thing is either providing me with a piece of data, updating something, deleting something (typical CRUD stuff) or even kicking off a process (instruction to read a file or turn on a light – smart lights).
The reason I say APIs are everywhere because they quite literally are. They are used on websites, in apps we use, smart light, smart plugs and most IoT things,
When talking about APIs its handy to know that there is a server and a client, the client (the 3-year-old) will send a request to the server (the baker of the cookies). That request is usually in the form of HTTP call, however each protocol or API standard has its own specified way that a request is to be sent and a response is received.
There are quite a few API standards when it comes to web services:
REST – The most popular of the APIs. They are extremely flexible and, in my opinion, the easiest to use. A client will send a request to the server, the server does a thing and will give back a response usually in the form of a JSON object.
SOAP – Another popular standard that was much more popular in its prime (yes, its old now). It functions with XML but I do not prefer to work with SOAP as it gets complicated quickly.
WebSocket – A lower-level protocol (it requires IP and Port) that does point to point communication. This is great if you require a high amount of data to be transferred in two ways efficiently and quickly, but it is much more complicated and harder to implement (again my opinion).
There are a few more but let’s stick to those for now.
Tell me more about Webhooks
We already covered that a webhook is a reverse API. They only provide communication in one way, meaning a client will subscribe to a webhook and the webhook will provide a response / data when its ready.
This differs from APIs because an API can communicate in two ways (bidirectionally). Let’s say that the server I want to request a cookie from has multiple types, chock chip, Biscotti, Gingerbread, and shortbread. With a REST API I can tell the Serer that I only want chock chip. If I use a web socket, I will get all the cookies, and if I only want chock chip, I will need to subscribe to the Chock Chip webhook of that server specifically. Here is a diagram to add to your confusion:
