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