RESTful HTTP and websocket in the same application?

Question

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?

• Elias Van Ootegem: "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?
• maple_shaft: Chrome Developer Tools if I am not mistaken allow you to open a websocket and send messages real time
• Marc: @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: @maple_shaft That's good but you need to be on a page with a WebSocket opened to the server.

Answer 1

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.

• Marc: 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.
• Myst: @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.
• PirateApp: 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