Should I use a REST API in addition to websockets?

Question

I am writing a web application for a simple, multiplayer dice game so the traffic from the client to the server is going to be pretty light and latency tolerant. The client will need real-time updates from the server so I was originally going to implement the game entirely in websockets. However, I've come across designs lately that mix websockets with a traditional REST api like Discord does.

What are the advantages of using just a websocket for all communications vs using the websocket to send realtime information to the client and the REST api to send actions from the client to the server?

Answer 1

There aren't rules about this. For example, in Elixir, in real time components of Phoenix (a web framework), all requests are made using WebSockets. It's hard to define any rules outside undestanding details about your project.

The purpose is the big difference between WebSocket and Http Requests. Http requests are stateless and request/reply. Websockets are message based system and it mantains a state.

There are other considerations, but I think the one described above is the most relevant. Here are some references related with your problem: 1 and 2.

In summary, there isn't any problem using two techniques at same time, it's best you use the technique that makes more sense in specific situation considering the characteristics of each one.

Answer 2

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:

1. 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.

2. 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.

3. 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.

4. Caching works really well for REST calls. If you get all the information you need through Websockets, setting up caching would be quite challenging.

5. 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.

6. 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.

7. 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.

Answer 3

My experience is to just push “ask client to refresh data” with the websockets and use as many normal HTTP requests to refresh the data as possible.

Why? Because you anyway need to use HTTP Requests for a lot of other things and it’s better to manage your complexity on one concept then in two.

It’s also way easier developing, because most logic you can test/build without needing to use the websockets logic. Tooling is usually also a lot better.

Doing everything on the websocket itself is probably an immature optimazation that you don’t need.