17

If an application has already an opened WebSocket for live feeds, should I use it over AJAX for the other communications with the server?

Because the connection is already opened, should we use it for requests that are Request/Response and not real time?

I prefer RESTful HTTP requests because I find them more easy to debug. You can use a browser with urls or curls to test what the API returns. You don't have to write code to open a WebSocket.

Would it be weird to have RESTful HTTP API and a WebSocket in the same application?

  • 1
    "you don't have to write any code to test the API" Could you explain this a bit more? What makes you think you don't have to test the API? – Elias Van Ootegem Apr 29 '16 at 12:46
  • Chrome Developer Tools if I am not mistaken allow you to open a websocket and send messages real time – maple_shaft Apr 29 '16 at 12:54
  • @EliasVanOotegem Good point. Sorry that wasn't clear. You still have to test the API with a unit project on the server side. What I mean is, if you want a quick look at what the API would return, you can use a broswer with the url. You don't have to write code to open a websocket. I updated my question. – Marc Apr 29 '16 at 12:54
  • @maple_shaft That's good but you need to be on a page with a WebSocket opened to the server. – Marc Apr 29 '16 at 12:57
14

One of the core design goals of Websockets is that it allows both HTTP and Websocket protocols to be communicated over the same port. It achieves this by explicitly requiring a client to perform a Websocket handshake with an HTTP Upgrade request. In this way the server can handle a standard HTTP request connection as well as an HTTP Upgrade request that is now upgraded to a persistent bi-directional duplex connection.

So yes, this is definitely a valid use case, however whether you SHOULD do this for your specific application is a different matter entirely. Websockets are useful and make sense where you have scenarios that the server must have the ability to send unsolicited data to the client (live feeds). HTTP protocol and REST services are useful where you want blocking synchronous client solicitation of data.

If your requirements are such that both of these make sense for your application then by all means you should use both. If however your only interaction with the server is live feed based then REST services are not appropriate. I think ease of debugging should rank rather low in importance in terms of System Quality Attributes that you should architect your design to.

  • 1
    That's what I was wondering. It makes sense to use websockets for real-time live feed but what about CRUD operations? It makes more sense in my mind to use a standard HTTP request for those. – Marc Apr 29 '16 at 13:38
  • 2
    @Marc, I wouldn't find it weird to separate CRUD operations and real-time concerns (one using HTTP the other Websockets)... but... I do believe you'll get better responsiveness from the server, as well as better performance, if you utilize the persistent connection (Websocket) for all your operations. This really depends on what your CRUD needs are, but I wouldn't shy away from a CRUD Websocket interface. – Myst Sep 24 '16 at 5:41
  • upvoted! newbie here, since you mentioned both are to be communicated over the same port, if you are fetching say stock prices from a live stream and due to heavy traffic the stream disconnects for a few mins, how would you get the data in between or what strategies exist to tackle that case – PirateApp Jun 26 '18 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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