You may start by asking yourself why do you need Websockets in the first place, as opposed to Server-Sent Events (SSE).
The benefits of Websockets, compared to SSE, are the support for binary data, and the ability to send the information both ways—server to client, but also client to server.
The drawback of Websockets, compared to SSE, is that it may be more complex to set up the infrastructure, such as configuring the firewalls (whereas SSE is just an ordinary HTTP request).
Therefore, you have not two, but three possibilities:
- Client to server communication happens through REST, and server-to-client goes through SSE.
- Client to server communication happens through REST, and server-to-client goes through Websockets.
- No REST—everything happens through Websockets.
All three approaches are fine, and it comes, essentially, to the tooling and your familiarity with the different approaches. Regarding the tooling:
Browsers tend to have better tools when it comes to monitoring REST calls, compared to SSE and Websockets. For instance, you can get quite a lot of information in the developer tools of your browser about the exact performance of a given HTTP call: how much time it spent sending the request, waiting, downloading the response. When you start getting issues with the performance of SSE/Websockets, you're pretty much on your own.
Regarding SSE vs. Websockets choice, it's also important to check how it integrates with the thing that you would use for the real-time updates, whenever it's RabbitMQ, Redis pub/sub, or something else.
Sooner or later, you'll want to access your API programmatically. Virtually any programming language can do HTTP requests, and many popular languages have libraries for SSE and Websockets. However, check how strong is the support for SSE/Websockets in the language of your choice, compared to the support for REST calls.
Caching works really well for REST calls. If you get all the information you need through Websockets, setting up caching would be quite challenging.
REST calls are made it parallel. To have this level of parallelism with SSE/Websockets, you need to open more than one channel, which is not straightforward to do, and costs you additional connections.
You have to think ahead about the way you would log the thing if you're using SSE/Websockets. With REST, reverse proxies and servers log the requests automatically for you.
How do you cope with DOS and DDOS with SSE/Websockets?
For a new project and if you don't have a strong expertise in one particular approach, it may be wise to follow KISS and YAGNI principles, and start with SSE for server-to-client traffic, and REST calls for client-to-server requests. But make sure that whatever decision you take now, you should be able to migrate later on with relative ease.