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

4 pointsby bethere5 tahun yang lalu3 comments

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 ?

3 comments

bruce5115 tahun yang lalu

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.

neximo645 tahun yang lalu

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.

bruce5115 tahun yang lalu

>> Some ISPs block websockets with some websites

While I'm assuming you have personal experience of this, and I hesitate to make absolute statements, if your connection is HTTPS end to end, I'm not sure how an ISP can "block" it. The ISP sees a regular web connection on port 443, and everything inside that is encrypted.

So I'm not sure _how_ it would even know it's web-sockets except perhaps for heuristics on traffic behaviour - and even then it must look similar to keep-alive or HTTP2.

With good planning it's easy to do multiple requests on a single socket (the requests themselves would be serialized over the socket, but the server could easily spawn threads to process each request, and then pump the answers back when they are ready.) The connection itself would be serialized, but the handling at either end could easily deal with multiple requests and responses.