CODEWITHSUNDEEP
web-servicesapihttpwebsocket
David Dahan
David Dahan

Reputation: 11192

How to create a full-duplex communication between API and various clients?

In my website, I'd like to create a public API that would allow clients (unknown people) to interact with my services. A classic REST API would work well in that case.

However, I need to be able to send events to the clients too. These events are not related to client HTTP requests. I saw "webhooks" are a way to deal with this. If I understood well, with webhooks, my service would send HTTP POST requests to a URL specified by the client, with event data inside this request.

I think websocket can be used too as a solution for this full-duplex communication need.

What I want to know, is which method would be the simplest for clients to implement to talk to my services? Simplicity is the key point here. The hard thing is that my clients can use various technologies (full websites with HTTP servers, iOS/Android apps without server, etc.)

What are implications for clients if I use REST API + webhooks? Websockets? etc? How to make a choice?

Hope it's clear (but not sure). Thanks :)

Upvotes: 4

Views: 3660

Answers (1)

mansilladev
mansilladev

Reputation: 988

I would consider webhooks a simpler solution. And yes, you understood it well, that with webhooks, a developer using your API would register a URL where your backend would POST event data. It's a common pattern that's used in APIs.

A great benefit of using a webhooks design is that a client/server connection does not need to stay open. After all, if events occur infrequently (i.e. only a few times per hour, or per day) or keeping a consistent connection open is a challenge, establishing a connection only when it's needed is rather efficient.

The challenge of using webhooks for you, the API provider, is designing an evented backend system that deals with change of state detection and reliable webhook calling mechanisms (i.e. dealing with webhook receiver URLs that are unresponsive or throw errors).

The challenge of using webhooks on the developer end is that they need to stand up a reliable web server that listens for the event POST data from your server.

Realtime APIs (i.e. based on Websockets, Bayeux/CometD) are really swell because that live connection means that new connections do not have to be established, which is particularly useful with very chatty sessions. Additionally, there are a lot of projects and companies out there that have taken care of the heavy lifting on the server and client with fully-baked libraries. One of those is Fanout.io which makes pushing messages between the client/server possible with just a few lines of code, utilizing XMPP, Bayeux, and Websockets when possible.

(I am not affiliated with Fanout, but I have used it)

So, to sum it up, webhooks are simple mostly because you are already familiar with the architecture needed to implement them, and the pattern is a well traveled one. If you are leaning toward a persistent connection approach, I would look at tools/platforms like Fanout because it takes care of the heavy lifting (i.e. subscribe/publish, concurrent connection scale, client/server libraries).

Upvotes: 7

Related Questions