
WebSockets versus REST? - DanielRibeiro
http://www.infoq.com/news/2012/02/websockets-rest
======
DougWebb
I think what lots of people are missing is that Websockets doesn't compete
with REST or SOAP, it competes with HTTP. Until now, programs written in
Javascript could only use one internet protocol: HTTP. Websockets brings low-
level TCP socket programming to Javascript, enabling the use of any TCP-level
protocol.

Of course, this happens within a sandbox that involves initiating the
connection over HTTP and tunneling the protocol through a server over port 80.
But that server can be a proxy that forwards the stream to any TCP service, on
any TCP port. We're back to the days when anyone could and did develop their
own protocols, and many of those became standards.

I suspect that we're going to see that kind of development again: people will
initially create their own protocols to use over Websockets, then they'll
recognize the benefit of tunneling existing standard TCP protocols to their
Javascript programs (how about an IMAP client written in Javascript?) then
finally someone will develop an HTTP client in Javascript.

~~~
cenuij
I think you have missed the mark by such a wide margin that I need to call you
on your bullshit.

> I think what lots of people are missing is that Websockets doesn't compete
> with REST or SOAP, it competes with HTTP.

Websockets of any reference are implentations of HTTP, your lack of knowledge
is not a badge of authority.

"Of course, this happens within a sandbox that involves initiating the
connection over HTTP and tunneling the protocol through a server over port
80."

I am sure that you have no clue about what your talking about, I will bring
this forward with the following statement:

"We're back to the days when anyone could and did develop their own protocols,
and many of those became standards."

Your name is not on any IETF bodies or standards, who are you exactly?

~~~
mahmud
_I think you have missed the mark by such a wide margin that I need to call
you on your bullshit._

Not a good start :-|

~~~
cenuij
yeah, it's a bad thing when tech beats bullshit :(

------
andrewvc
So, in a nutshell, we're seeing a swing back to RPC. I think that's great,
bidirectional RPC is much nicer than REST.

REST is great, but a good portion of the time proper rest begins to feel like
square peg round hole, that's why we see endless discussions of 'proper' rest.

~~~
javascriptlol
Unfortunately, during our circle back to the 1970's we lost UDP, which is
essential for real time protocols.

~~~
udp
Exactly. Flash sockets are TCP only (proprietary Adobe protocols aside), and
it seems WebSockets ended up without any UDP support either.

The overhead of TCP is just ridiculous when you're trying to implement real-
time game movements with dead reckoning, etc.

~~~
drawkbox
Unity has UDP sockets and yes all good games that require fast real-time
action need UDP. Adobe had it partially in their latest Flash Media Server
RTMFP protocol but it was very limited.

RUDP or Reliable UDP is the best of both.

Here's some great info on UDP vs TCP and only using one or the other:

UDP vs TCP [http://gafferongames.com/networking-for-game-
programmers/udp...](http://gafferongames.com/networking-for-game-
programmers/udp-vs-tcp/)

Characteristics of UDP Packet Loss: Effect of TCP Traffic
<http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM>

~~~
waffle_ss
RUDP sounds very weird... why would you use it instead of TCP? At a glance, it
looks like the only difference is RUDP doesn't enforce packets being received
in-order (being a message-based protocol), while TCP does (being a stream-
based protocol).

~~~
drawkbox
The great thing about UDP with a reliable layer on top is you can choose if
you want an ACK back for any 'critical' data. Otherwise you can just ignore
order or whether the endpoint receives it or not. It is a broadcast rather
than a hard line essentially.

For instance let's say you have some physics update and for some reason you
needed it networked, with many objects, receiving only 70% of those for many
different elements may be just fine (discarding any you receive after that are
older maybe for this example)...you may not need reliable acknowledgement that
they received for most of them if any. But you definitely need to know when an
enemy is killed so you make that a critical message to the server RPC'd to the
clients and use a reliable flag which then will expect validation. Same with
ordering... use when needed with RUDP or custom layer on UDP for reliability.

TCP does all this for you and works great for files/http etc. but doing this
for all messages is great overkill in real-time games lower than turn based.
And mixing TCP/UDP arguably causes some slowdown to UDP due to TCP queuing.
RUDP solves all these issues and is flexible to reliable messages and just
firehose broadcast.

<http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol> Designed by
none other than Bell Labs...

Also SCTP was created to solve RUDP like issues as an official standard (RUDP
is a draft) but standards take time:
[http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...](http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)

------
almost
Apples vs. Oranges: discuss!

(I'm quite happy with my RESTful API that allows subscription to resources via
Websockets. This works very nicely when your resource representations include
their own href)

~~~
csears
I had been thinking of something similar... Use WebSockets for pub-
sub/broadcast notifications, but keep REST/XHR for all the normal request-
reply operations. It seems like they could be very complementary.

In your API, does the WebSocket subscription deliver the full content of the
updated resource? Or does it just provide a change notification which triggers
a GET to pull the full content?

~~~
almost
Full content. I have a layer over Backbone.JS on the client side that provides
an identity map for models (all of which are identified by uri). When a
representation is recieved it grabs the relevant model and updates it which
makes any views listening on that model also update themselves in the normal
backbone way. I think it's kind of neat :)

~~~
dalyons
I've done exactly this before. It works really well. For endpoints that
support it, you can put a subscription channel id in the normal REST resource.
If the client sees the pubsub channel, and understands what to do with it, it
can subscribe for updates via websockets; if it cant/chooses not to, if can
just refresh the resource via standard http GET.

~~~
almost
What's especially nice is Websockets have their own url type (ws://) you can
just include a link to the Websocket's endpoint for the resource for the API
client to follow. Reductions in the amount of custom stuff that has to be done
is always good :)

------
farhanpatel
I belive that this is the future. With things such as Backbone.Sync written to
communicate with websockets(via Socket.io). We can Keep Backbone models in
sync easily.

<https://github.com/logicalparadox/backbone.iobind>

Fog Creek's new Trello syncs data using websockets as well. Its quite
effective and works well. Trello also falls back to a regular short-polling
system if it needs to.

~~~
dodger
The Trello team loves WebSockets for push, and we did all of our initial
prototyping and a lot of the first version doing RPC over the socket for
writes and gets. However, now that we're supporting a REST API for other
services to integrate with, we're moving everything other than pushing updates
over to that so that we only have to support one API as we grow Trello's
feature set. If we decide to go back to making requests over the socket, my
best guess is we'll use the REST semantics and just send method, URI, and args
in a WebSocket message and expect a response.

------
prodigal_erik
If anything, this is understating the problem that authors just aren't doing
the design work to provide addressable, reusable resources to the rest of the
world. They either haven't noticed or don't care that siloed javascript apps
are destroying the web.

~~~
javascriptlol
The web was never a set of "addressable, reusable resources".

~~~
prodigal_erik
Would you please explain? What is the web, in your view, if not that?

~~~
javascriptlol
I dispute the existence of "resources" in the abstract sense people are trying
to achieve with respect to REST. The web is just a collection of stuff with
ephemeral links to go from thing to thing. Obviously, these could be called
"resources", but not in the coherent sense implied by REST.

------
hengli
[http://stackoverflow.com/questions/6806263/websocket-api-
to-...](http://stackoverflow.com/questions/6806263/websocket-api-to-replace-
rest-api)

One of the main practical problems is that websockets take a second or 2 to
start up, clearly too slow.

~~~
zaphoyd
Where does this article talk about >1s connect times for websocket? The
websocket handshake is a single network round trip (discounting any added by
TLS if you are using it) and the initial client message frames can be sent in
the same TCP packet as the handshake. A websocket connection should not add
any more latency than HTTP(S) connections.

------
Valdemar
Where did people get the notion that WebSockets have anything to do with REST
or http?? websockets are a simple tcp connection, you know... like the one
that CARRIES http!

So when people say stuff like this:

> First and foremost, how do you represent a URI? Second, how do you represent
> the HTTP methods (GET, PUT, POST, …)? A

How do we represent HTTP? Well, how about using HTTP ?!?!

(is everybody taking crazy pills, or am I missing some HUGE part of this
discussion?)

------
tantalor
If you're not talking to web browsers, you could replace WebSockets with any
bidirectional medium, e.g., zeromq.

------
vdurbha
Here's what Roy Fielding said on the REST mailing list when asked about what
he thinks about Websockets.

[http://tech.groups.yahoo.com/group/rest-
discuss/message/1581...](http://tech.groups.yahoo.com/group/rest-
discuss/message/15818)

"It would be a different style of interaction. Generally speaking, REST is
designed to avoid tying a server's connection-level resources to a single
client using an opaque protocol that is indistinguishable from a denial of
service attack. Go figure."

I think Websockets relaxes the client-server constraint (and maybe some
others). As long as developers understand the consequences, it should be fine
I guess.

------
wooptoo
None of them has to 'win' since they satisfy different needs. There is a place
for REST services - where data was introduced in the past and needs to be
queried or manipulated. Just like there is a place for Websocket services -
data is realtime. One service (like Facebook) could use the best of both. REST
for serving user details and Websockets for the chat.

------
alexro
Why focus on client vs. webserver communication layer? Think about using
websockets between your app and database api. REST wouldn't do there, but
websockets opens up new opportunities for dynamic languages.

