Should a REST API be used when a websocket is already open?

Question

Background: I was working on a web-socket application integrated into a more conventional http request based website that uses REST APIs.

Task: I need to retrieve user history from the database for that application. It is a given that the application is open when we need to retrieve this history. Further, triggering updates/deletes/modifications of history in the database are not relevant(and will not be in the future either).

Analysis: Based on reading several online resources, I got the general idea that REST APIs are preferred due to scalability, conversion to binary format for large datasets and caching while websockets allow server to frontend communication and higher speed since the connection need not be opened/closed everytime. In my application however, I feel like using the websocket itself might be better since:

• It's already going to be open while an additional http request is extra load
• The data I am sending is essentially text and only a small chunk of the entire history is required in one go
• Why go through authentication/filtering again when an authenticated websocket is already open? Also, why write serialisers and define an api when the updation/deletion methods they provide are never going to be used?

Question: TL,DR I feel like a simple function in my websocket application would do the job of history retrieval better than a REST API in my case. However, I am a newbie and don't want to budge from standard design without being sure that my analysis of the situation is reasonable. Could someone help me understand if/any points that I might have missed?

Answer 1

A complex question.

On the face of it, yeah, if you have a websocket connection open, you should use it for everything.

If you app has a limited set of functionality which is all served by a single back-end application, and websocket is working for you already, then this is going to be fine.

However. What if your get history API is a separate application. You have divided everything into micro-services and load balanced this across more boxes than your application backend because its more resource intensive.

You can't call it directly via your existing websocket connection. That connects to your app back-end. So you would have to add a method to your back-end and get it to call that api and return the result. This adds a small amount of load and complexity to your back-end. Is this acceptable? What if you have several such APIs?

Also, if you only have one connection you are only sending/receiving one message at a time. are you happy to delay your chat message feed for example while the big image downloads.

The big benefit of REST is that because it uses HTTP a whole lot of hard networking problems are handled for you by the browser. Sure its not as efficient as other protocols. But it is easy