2

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?

Improve this question

1 Answer 1

Reset to default
0

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

Improve this answer
1
  • Wow, I hadn't even thought about the multiple application scenario although it is a very possible framework! Image/Video loads are already handled in an independent manner, so we are only talking about a limited amount(paginated) of text in this scenario. I guess a REST API affords future flexibility while using the websocket would limit this.
    – vonSchweetz
    Commented Jan 31, 2020 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.