Mark posted a really nice article to InfoQ: WebSockets vs. REST?
From what I understand of Websockets, its bascially used to set up a two-way socket connection and not really an application protocol. What worries me the most is that you’ve basically rolled back 20 years of protocol consolidation, and we’re now back to a free-for-all of everybody’s pet protocol. Not so bad if your client and server are a tightly coupled, unreusable UI application. Really bad if you’re writing a web service that is supposed to be reusable by unknown heterogenous clients. With Web Sockets, web services are not only going to have to negotiate the media type, but also the application protocol. Seems like a huge step backward to me in terms of integration. Did we forget all the problems we had with Oracle Forms, PowerBuilder, Visual Basic and all the UI/framework specific protocols all those developer frameworks introduced? Do we really want to go back to those days?
What about security issues? With an anything-goes socket protocol, isn’t this a security nightmare for our operations folks?
Disclaimer: You could say that I’m both biased and threated by the concept of Web Sockets given my involvement in REST frameworks and APIs. But in all honesty, I’d be very happy to embrace a new protocol that is both ubiquitous and easily supportable and interoperable in many different languages and platforms. There’s much to be said about the simple request/response text-based approach of HTTP (and REST over HTTP). While it may not be uber-efficient, its just so easy to hack and support.
Bill the Plumber 
Feb 28, 2012 @ 17:56:55
I guess the main drive behind web sockets is the bi-directional communication which I think is a huge step forward to the HTTP long-polling over a keep-alive connection. But I agree that web sockets is more like a TCP channel and that common protocols probably need to evolve on that again. I haven’t really looked at it from this perspective.
Feb 28, 2012 @ 19:09:32
I just don’t believe that there’s a real need for a bi-directional communication protocol as the applications that may need it are in the minority.
Feb 28, 2012 @ 19:39:05
Having spent the last 16 months building a fully async web application with client and server which uses a REST API to trigger events which are then delivered via HTTP long-poll to the browser I fully believe that this is a good way of building interactive applications. I would have loved to have a built-in and tested cross-browser mechanism for pushing data from the server to the client. You’re looking at it from a protocol perspective. For me it is just a robust channel for delivering data to the client.
Feb 29, 2012 @ 08:51:10
With regards to security the following makes for interesting reading:
http://www.ietf.org/mail-archive/web/hybi/current/msg08668.html
http://www.ietf.org/mail-archive/web/hybi/current/msg08758.html
Feb 29, 2012 @ 10:28:16
From our experience, clean REST JSON API are a lot more “flexible over time” than any other API ever used.
Using optional JSON blocks, automatic conversion from and to old JSON, separate URI path for brand new API, good content type names, you can keep a rapidly evolving REST API answers old queries for years. And this without bloated code.
From my point of view, the API I see are respecting more and more the clean REST JSON API concepts, and applications will highly benefits from an “API Listener Events” capability.
We are seeing the huge spikes of queries at every 00 on the hour because of basic cron polling expressions. This is crying for Websockets!
Feb 29, 2012 @ 13:41:22
Fred, I’m curious, why do you think a Websocket solution will help with your huge spikes in queries for “basic cron polling expressions”? You’ll still have the same load/concurrency issues with a Websocket solution as with an HTTP solution. Async HTTP APIs can help with idle polls, and you can still use a simple, easy to support protocol (HTTP).
Feb 29, 2012 @ 16:57:22
In our environment (CI tools), every tools wants to react to events from other tools (new commit, new build, new release, new artifact, …) and most integration is done using polling.
For example in Jenkins, many users just say: Check for new stuff every hour at 00 minutes.
I think if Jenkins had out-of-the-box easy websocket integration to VCS servers, repository manager, it will make the HTTP chatting more efficient.
For example, a common pattern we see when products are being released:
– Very long (weeks) quiet time were no new release are made,
– Then fast releases for new versions (rc, path, final),
– Then quiet again.
During the all time most build tools just have a rude 12 hours cache. I think (still not proven, like your fears :), Websockets will greatly improve the response time, synchronization and level of chat on the net.
Feb 29, 2012 @ 17:01:12
Its not just about response times. HTTP hasn’t been built and designed for server push. We need a proven and robust technology for the server to make a connection to the client and that doesn’t exist yet in the web space. All there is are hacks and workarounds but no native support for this type of communication. We’re basically looking at TCP for the web.
What Bill is talking about is at a much higher level in the stack and although his concerns are valid they don’t render the request moot to have a solid two-way communication.
Mar 01, 2012 @ 18:56:54
I’m saying that push is (or should) be a minority case for most applications. I also don’t consider HTTP pulling a hack, especially since there are already nice data formats which can publish queued messages (Atom) or REST interfaces like HornetQ’s REST interface that are a bit more efficient than Atom.
Distributed Weekly 144 — Scott Banwart's Blog
Mar 02, 2012 @ 16:04:31
Sep 05, 2014 @ 20:23:43
Do you have any updates or insights into this debate?
We have been using websockets in our real-time mobile network monitoring pages for a couple of years now and they work quite well. We are investigating an update and redesign of the site which uses both websockets and ajax calls. I am trying to get a feel for where the line separating the two approaches is.
Any thoughts?
Sep 05, 2014 @ 20:36:12
If you have a REST backend, there’s a good change that the services can be re-used by non-browser applications. Other than that, I’d personally only use websockets if I needed server push.