Despite their vague handwaving, I do not see what this offers over HTTP pipelining. Why layer REST on a websocket on what is an HTTP-1.1 capable server when we can just layer REST on a HTTP-1.1 server?

To the extent that you can't send multiple requests without getting answers, that's your fault for using synchronous requests, not for using not-a-websocket.

WebSockets aren't performance magic. They're slightly glorified TCP sockets. If you've already got a TCP protocol (like, say, HTTP-1.1), it may be convenient to put a WebSocket interface around it, but there's no other advantage. And this is a particularly weak case since if we support websockets in the first place we almost certainly have full HTTP1.1 pipelining support.

>To the extent that you can't send multiple requests without getting answers, that's your fault for using synchronous requests, not for using not-a-websocket.

fewer open connections while awaiting results, avoiding browser limitations

Am I mistaken in my understanding that WebSockets is a stateful protocol? If your problem maps well to resource oriented architecture, when would the benefits of switching to this outweigh the fact that you'd be giving up response caching and scaling on a per-connection basis?

WebSockets are sockets with a very small bit of goop layered over them. In terms of the state you are talking about, they basically have the same amount of state as a TCP socket, which itself is mostly "connected" or "not connected". So the question of the "statefulness" of websockets, in the sense you mean, is ill defined, because statefulness is or is not added by higher layers, just as with TCP sockets.

This feels a little redundant now that we have SPDY getting implemented in more and more places, particularly as the browsers that do best support WebSockets also support SPDY.

But what about WebSockets in non-browser contexts. I have to wonder if Square does this with its SocketRocket http://corner.squareup.com/2012/02/socketrocket-websockets.h...

Think of desktop apps that keep a connection to the server and are awaiting messages from it. I think it might get interesting, maybe not the best application of WebSockets, but interesting. Your Email client wouldn't have to poll every X seconds to see if new mail has arrived.

Both browsers and servers need something like SwaggerSocket this--SPDY is a good step but i feel it's more of a "pipelining" solution rather than an async + multiplexing issue.

While I think there's going to be a place for APIs to use async bidirectional communication (e.g. pretty much anything people use webhooks for) I don't think it makes sense to shoehorn in 'REST' (which in the quick start, is more RPC than REST). REST makes sense for HTTP, and I think something else (I don't know what) will make more sense for websockets. Maybe this is a good bridge to something better though.

As a subprotocol, it leverages the readability of REST into something much more efficient. Maybe pseudo-REST is a better term

Be very very careful when looking at that graph people! See, latency is the deciding factor as proven here: http://www.peterbe.com/plog/are-websockets-faster-than-ajax

Yes, the graph in the blog is just a sample. There will be a detailed post about performance coming, including access from browsers and non-browsers across fast and latent connections. The chattiness of REST across slow connections is one of the biggest advantages to the socket protocol. How the client handles the true async behavior of the sockets (not just via callback in the client!) makes a massive difference in performance.

Great demo, and I'm glad we are starting to explore web apis outside of http, but let's not forget that Websockets generally fail over mobile networks due to the use of invisible proxying by carriers, etc.