Websocket API to replace REST API?

Question

I have an application whose primary function works in real time, through websockets or long polling.

However, most of the site is written in a RESTful fashion, which is nice for application s and other clients in the future. However, I'm thinking about transitioning to a websocket API for all site functions, away from REST. That would make it easier for me to integrate real time features into all parts of the site. Would this make it more difficult to build applications or mobile clients?

I found that some people are already doing stuff like this: SocketStream

Answer 1

That's not a good idea. The standard isn't even finalized yet, support varies across browsers, etc. If you want to do this now you'll end up needing to fallback to flash or long polling, etc. In the future it probably still won't make a lot of sense, since the server has to support leaving connections open to every single user. Most web servers are designed instead to excel at quickly responding to requests and closing them as quickly as possibly. Heck even your operating system would have to be tuned to deal with a high number of simultaneous connections (each connection using up more ephemeral ports and memory). Stick to using REST for as much of the site as you can.

Answer 2

The only problem I can using TCP (WebSockets) as your main web content delivery strategy is that there is very little reading material out there about how to design your website architecture and infrastructure using TCP.

So you can't learn from other people's mistakes and development is going to be slower. It's also not a "tried and tested" strategy.

Of course your also going to lose all the advantages of HTTP (Being stateless, and caching are the bigger advantages).

Remember that HTTP is an abstraction for TCP designed for serving web content.

And let's not forget that SEO and search engines don't do websockets. So you can forget about SEO.

Personally I would recommend against this as there's too much risk.

Don't use WS for serving websites, use it for serving web applications

However if you have a toy or a personal websites by all means go for it. Try it, be cutting-edge. For a business or company you cannot justify the risk of doing this.

Answer 3

Do I want updates from the server?

• Yes: Socket.io
• No: REST

The downsides to Socket.io are:

• Scalability: WebSockets require open connections and a much different Ops setup to web scale.
• Learnin: I don't have unlimited time for my learnin. Things have to get done!

I'll still use Socket.io in my project, but not for basic web forms that REST will do nicely.

Answer 4

WebSockets (or long polling) based transports mostly serve for (near) real-time communication between the server and client. Although there are numerous scenarios where these kinds of transports are required, such as chat or some kind of real-time feeds or other stuff, not all parts of some web application need to be necessarily connected bidirectionally with the server.

REST is resource based architecture which is well understood and offers it's own benefits over other architectures. WebSockets incline more to streams/feeds of data in real-time which would require you to create some kind of server based logic in order to prioritize or differentiate between resources and feeds (in case you don't want to use REST).

I assume that eventually there would be more WebSockets centric frameworks like socketstream in the future when this transport would be more widespread and better understood/documented in the form of data type/form agnostic delivery. However, I think, this doesn't mean that it would/should replace the REST just because it offers functionality which isn't necessarily required in numerous use cases and scenarios.

Answer 5

I'm thinking about transitioning to a WebSocket api for all site functions

No. You should not do it. There is no harm if you support both models. Use REST for one way communication/simple requests & WebSocket for two way communication especially when server want to send real time notification.

WebSocket is a more efficient protocol than RESTful HTTP but still RESTful HTTP scores over WebSocket in below areas.

1. Create/Update/Delete resources have been defined well for HTTP. You have to implement these operations at low level for WebSockets.

2. WebSocket connections scale vertically on a single server where as HTTP connections scale horizontally. There are some proprietary non standards-based solutions for WebSocket horizontal scaling .

3. HTTP comes with a lot of good features such as caching, routing, multiplexing, gzipping etc. These have to built on top of Websocket if you chose Websocket.

4. Search engine optimizations works well for HTTP URLs.

5. All Proxy, DNS, firewalls are not yet fully aware of WebSocket traffic. They allow port 80 but might restrict traffic by snooping on it first.

6. Security with WebSocket is all-or-nothing approach.

Have a look at this article for more details.

Answer 6

I would consider using both. Each technology has their merit and there is no one-size fits all solution.

The separation of work goes this way:

1) WebSockets would be the primary method of an application to communicate with the server where a session is required. This eliminates many hacks that are needed for the older browsers (the problem is support for the older browsers which will eliminate this)

2) RESTful API is used for GET calls that are not session oriented (i.e. not authentication needed) that benefit from browser caching. A good example of this would be reference data for drop downs used by a web application. However. can change a bit more often than...

3) HTML and Javascript. These comprise the UI of the webapp. These would generally benefit being placed on a CDN.

4) Web Services using WSDL are still the best way of enterprise level and cross-enterprise communication as it provides a well defined standard for message and data passing. Primarily you'd offload this to a Datapower device to proxy to your web service handler.

All of this happen on the HTTP protocol which gives use secure sockets via SSL already.

For the mobile application though, websockets cannot reconnect back to a disconnected session (How to reconnect to websocket after close connection) and managing that isn't trivial. So for mobile apps, I would still recommend REST API and polling.

Another thing to watch out for when using WebSockets vs REST is scalability. WebSocket sessions are still managed by the server. RESTful API when done properly are stateless (which mean there is no server state that needs to be managed), thus scalability can grow horizontally (which is cheaper) than vertically.