Very quick explanation:
An API is an interface that the maintainer of a service / module exposes to the outside world so that they can interact with said service / module.
So for instance, Reddit has an API, and you can request things like the list of comments on a specific post based on its unique ID.
The definition of a webhook is a little more broad because it’s used a little more liberally. Slack for instance used to call webhooks endpoints that you could hit to write messages (as yourself) in a specific slack room. This is, for all intent and purposes, just an API call.
Another use for the word is for instance a functionality offered by PagerDuty (an incident response provider, that send alerts to people when something goes wrong). In this case, a webhook is something you can configure to trigger API calls so that every time something happens (say any time someone resolves an incident in PagerDuty), PD makes an API call to the endpoint you provided them. This can be used to automatically update a status page on your website for instance. This effectively becomes a notification pipeline. You would need to write a service that is able to receive these API calls, and act on them.
With an API other computers can request information from your computer.
With a webhook, your computer will get information from another computer when it’s ready.
For example, I’ve got an API called WhatTimeIsIt where other computers can send requests and my computer will return the time.
Alternatively, I’ve got a webhook called TimeForDinner that will send my computer a message once dinner is ready.
Let’s say you’re a kid playing outside waiting for your mom to make dinner. An API call would be popping your head in to ask whether dinner is ready. A webhook would be waiting until your mom calls your name to know that dinner is ready.
An API call is about proactively getting information while a webhook is about reactively being notified that something has changed.
There are more specifics but I wanted to provide a ELI5 beyond the other answers already given
API is any interface exposed by a piece of software, specifically one intended for use by other software rather than direct human interaction.
REST API is a specific type of API. I’m sure there are pedantic exceptions, but it’s generally understood to be using HTTP protocol, which is the same you use to browse a website.
REST API is set of loose conventions for how to structure such an API. The details are probably not very relevant at this stage, you can look it up and find lots of arguments about what exactly constitutes a “RESTful” API.
That type of API uses a “synchronous” request-response pattern, i.e. you make a request to the server and it responds immediately with some data. The server never sends you data except in immediate reply to a request. This is the same as when you type the address of a web page in a web browser and hit enter – the browser sends a request to that address and the server responds with the data that makes the web page.
Webhook is a sort of inverted version of that pattern. The ‘web’ part means it’s also using the HTTP protocol. You have to have your own server to receive requests. Usually you have to register in advance in some way, you tell their server “notify me when X thing happens in your system” and give them the web address of your own server. Then whenever that event occurs their server will request to your server, your server will then run whatever code you want to run, and reply to their server to acknowledge receipt of the webhook. Often the system will be designed so that they will retry sending the webhook if your server does not acknowledge the message with an appropriate response (for example if you had an error in your server).
Common uses of webhooks are for event notifications. But can also be when you need an “asynchronous” reply. For example maybe you made a REST API request to their server for something that takes a long time to process. Their server replies immediately to say the request was received. Then some time later you get a webhook which delivers the result of that processing.
Web Sockets are different again. They are a protocol for two-way communication between systems. So instead of a strict request-response pattern, with one system always the requester and the other always the responder. With Web Sockets instead you establish a ‘channel’ between the two systems, and either party can send a message on that channel at any time. A typical example would be a chat app.
Latest Answers