WebSocket APIs vs. REST APIs – will it make a difference?

Question

For all our client and server interactions (APIS) - we are just using websockets. It is a gaming application.Its a proof of concept used by close to ~50 people. The application feels snappy compared to say our previous REST API implementation. But of course we've not built for scale.Now, we want to build a scalable version of it. Are there inherent limitations on why people aren't using websocket for APIs instead of REST APIs ?

bruce511 · Accepted Answer

So, with a REST connection, the client makes a connection, sends a request, gets a response, closes the connection. You might have 1000 "simultaneous users" but at any one time that might mean only 100 actual connections in progress.
With WebSockets the connection is opened, then held open. So 1000 users means 1000 connections. So this is a limitation in the sense that there will be a max number of connections your OS can handle, and as the connection pool gets large there is some overhead in managing that connection list.
There will be some minor traffic to each connection (Ping/Pong) every minute or so to keep the connection open.
Websockets perform better because the connection is already open. So the client can push data quickly with no overhead. Equally the server can push data at the client which it can't do in a REST situation. Depending on your requirements WebSockets may be less actual network traffic because there are no polling REST clients "just checking for new info".
In most API situations REST is perfectly sufficient, and programmers are familiar with it, so it's easy to default to that. In most API situations data changes infrequently, and does not require immediate update. Games are different because data changes _very_ fast (depending on the game) and of course in most cases requires immediate update.
For your situation (with the data you provided) there's no absolutely right answer, but if the game is multi-player and real-time, then sockets are likely to be a good option.

neximo64 · Answer

I would find it a bit strange if you said the application feels a bit snappy vs your previous implementation on REST. I am guessing pretty much that you are in an eyeshot of your server in the figurative sense.
Websockets has its troubles. Some ISPs block websockets with some websites so you end up falling back to long polling and it becomes taxing to get a reliable implementation going - some clients just cant connect to a pure websocket.
The other is the upfront handshake has a cost or over an unreliable connection, say with a mobile app where REST tends to shine a bit more.
Then theres the ability to cache responses across geo-regions, a websocket cannot do this.
The other issue is with a REST request you can also do multiple requests at once, with websockets its one at a time, or having multiple websockets to get round that - which makes it worse off.