

Introducing SwaggerSocket: A REST over WebSocket Protocol - jfarcand
http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol

======
jerf
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.

~~~
aaronblohowiak
>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

------
T-R
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?

~~~
jerf
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.

------
jameskilton
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.

~~~
SupermanScott
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...](http://corner.squareup.com/2012/02/socketrocket-
websockets.html)

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.

------
johns
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.

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

------
peterbe
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>

~~~
fehguy
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.

------
rizwan
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.

