Webhooks

Webhooks are for server to server communication. They work by one server telling another server that it wants data sent to a certain url when something happens.

This article talks about some uses of webhooks in popular services. This organization talks a lot about using them in the context of RESTful APIs.

Websockets

Websockets are (usually) for server to browser communication. The server hosts a websocket server, and clients can open a connection to that server. This is popular now mostly because it is faster and less resource-hogging than older ways of solving the problem, like long-polling/COMET.

It is possible to connect 2 servers using websockets, but that is not usually what they are used for.

The confusion

Even though one of these is (exclusively) server-server and one is (mostly) browser-server, these technologies are often discussed in the same places, almost like they are solving the same problems. If you look up the chain high enough, you see that they both solve the problem of “real time” communication, but they solve different aspects of this problem in very different ways.

One situation where there may be a direct comparison is if you are building an API that will be consumed by a third party server. In that situation, you could provide a webhook API or a websocket API. Both allow the third party to get updates quickly:

• If you choose webhooks, that third party will still have to figure out a way to push the changes you are telling them about to their client’s browsers.
• If you provide a websocket API, the third party can just set up their site so each of their users connects directly to your websocket API, and their servers have to do less work.