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?