Choosing the scenario of using Web Sockets in standard HTTP REST API

I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.

That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:

  1. Client sends HTTP request
  2. Server replies about registering request
  3. Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on) That is all in a nutshell.

And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.

But I am a bit confused in choosing one of two ways to use web socket (WS).

Variant A. The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.

Variant B. The server sends all data to the client via WS without HTTP at all.

What variant is more suitable? Or maybe some other variants?

I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.

Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.

Back to Top