WebSockets versus REST?
infoq.com
infoq.com
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.
> 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?
Not a good start :-|
As parent said, they only implement HTTP for handshaking. Then you switch to the websocket protocol.
To quote websocket.org:
The protocol switch from HTTP to WebSocket is referred to as
a the WebSocket handshake. (...) The browser sends a request
to the server, indicating that it wants to switch protocols from
HTTP to WebSocket. (...) At this point the HTTP connection breaks
down and is replaced by the WebSocket connection over the
same underlying TCP/IP connection.
SPDY competes with HTTP.
Time for a plug too: my https://github.com/ypocat/ws-rpc and https://github.com/ypocat/ws-flash-client extensions for the mean and lean "ws" Node.js WebSocket server. (Reason for creating both of these was very simple - socket.io did not work out for me.)
The point of REST is operating with resources as building bricks of your API, and using only four CRUD operations on them (or on their collection). Besides, for testing purposes it is good to still have REST API to test it with curl or some web client in your code.
So what I'd suggest is to continue building REST API, but create a smooth REST2WebSocket layer to make your REST requests through WebSockets. Like "{'method': 'PUT', 'resource': '/api/users/john', 'data': '\{\'name\': \'Paul\'...".
On non-rest API you can get in trouble mixing actions and resources, so you can get things like {'action': 'list_users'}, {'action': 'rename_user'}, {'action': 'user_ban'}, {'action': 'rename_user_and_email'}, {'action': 'list_active_users'}
While on REST API you are at least consistent that user-resource is /users/, that concrete user is /users/<user_id> and that only operations are CRUD on either all users -> /users/ or on concrete user /users/<user_id>. That gives so much more clarity (+ caching reads, + only open transactions on POST/PUT/DELETE).
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.
The overhead of TCP is just ridiculous when you're trying to implement real-time game movements with dead reckoning, etc.
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...
Characteristics of UDP Packet Loss: Effect of TCP Traffic http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM
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...
I'm not saying that's good or bad.
Back in college on a distributed systems course, one of the projects was exactly to build that because the professor wanted to produce somewhere between UDP (more than) to TCP (less than).
On the other hand they, the w3c and the browser vendors, are working on unreliable (ie, UDP) peer to peer standard based off the WebRTC stuff so for those applications that can tolerate the unreliableness (ie, voip, video and real time games) it's not far off.
I don't see why - REST seems extremely elegant to me.
In any case, they solve completely different problems. REST is a set of constraints that ensure your architecture will be scalable, reliable, efficient (by allowing multiple levels of caching), easy to evolve (by being extremely decoupled) and linkable.
WebSockets throw away all that to ensure you can have low latency realtime bidirectional communications.
There will never be an enviable end-user Single Page Application built on a purely REST architecture style since REST/HATEOS promotes the idea of dumb clients driven by a single server view, in a page-by-page mode Netscape 4 would be proud of. This is great if you're building one of the turn-based games of the 90s but the REST of the world has moved - and the talented kids who can cut stellar client side apps aren't doing it with a restricted HATEOS mindset.
So while Google makes arguably the best REST client with Chrome, they're not wasting their time trying to restrict their Single Page Apps around HATEOS constraints. Instead they're investing heavily in trying to move the web forward with technologies that actually improve end-user experience like WebSockets and SPDY - rather than wasting their time chasing REST compliance badges, that's what REST cults do.
Of course they do. WebSockets are stateful - immediately less scalable and reliable, since a client is tied to a server during the session -, they can't be cached - much less efficient for images, videos, etc -, are tied to particular implementations instead of standards and aren't linkable.
they just don't add the unnecessary cruft and overhead to get their stellar latency and response times.
REST doesn't have any "cruft". In fact, REST only restricts, it doesn't add anything.
There will never be an enviable end-user Single Page Application built on a purely REST architecture style since REST/HATEOS promotes the idea of dumb clients driven by a single server view, in a page-by-page mode Netscape 4 would be proud of. This is great if you're building one of the turn-based games of the 90s but the REST of the world has moved - and the talented kids who can cut stellar client side apps aren't doing it with a restricted HATEOS mindset.
You're mistaken. Nothing about REST or HATEOAS prevents a web application from serving Javascript that then calls a RESTful API dynamically, using PushState to change the current resource URI locally.
In fact, pushing and running code on the client (code-on-demand) is one of the constraints (albeit optional) of REST, as specified in Fielding's dissertation. Your claim that REST promotes dumb clients is wrong.
So while Google makes arguably the best REST client with Chrome, they're not wasting their time trying to restrict their Single Page Apps around HATEOS constraints. Instead they're investing heavily in trying to move the web forward with technologies that actually improve end-user experience like WebSockets and SPDY
What Google service uses Websockets, exactly?
And there's nothing unRESTful about SPDY. You don't seem to understand what REST means. REST is not HTTP.
>> Of course they do. WebSockets are stateful - immediately less scalable and reliable, since a client is tied to a server during the session -,
And so does every other persistent TCP service but you don't see Spotify or Skype failing unreliably to handle their own scalability. You don't need a single server to handle every connection, you can load balance TCP servers just like everything else.
>> they can't be cached
Of course they can, web sockets just provide a client/server tunnel - you can cache on the server like any other RPC service. You can also cache in the browser with javascript vars or localStorage.
>> much less efficient for images, videos, etc -, are tied to particular implementations instead of standards and aren't linkable.
This makes no sense - how exactly is it less efficient when you can make the same request/response with less overhead. You can still use HTTP/SPDY for asset retrieval and web sockets for bi-directional data/comms. Trying to force bi-directional comms with HTTP is ladded with in-efficient hacks.
>> You're mistaken. Nothing about REST or HATEOAS prevents a web application from serving Javascript that then calls a RESTful API dynamically, using PushState to change the current resource URI locally. >> In fact, pushing and running code on the client (code-on-demand) is one of the constraints (albeit optional) of REST, as specified in Fielding's dissertation. Your claim that REST promotes dumb clients is wrong.
Alright genius and which popular SPA app downloads an entire page with on-demand scripts inside? Most SPAs combine and minify most their scripts upfront and when they are fetching external .js, they're just fetching CDN-cached .js and not a '.js scripts in a REST-infected HTML page with enhanced scripts' that you seem to suggest.
>> What Google service uses Websockets, exactly?
Gmail. Heard of it?
>> And there's nothing unRESTful about SPDY. You don't seem to understand what REST means. REST is not HTTP.
The protocol themselves don't, but the infectious sheeps who can't ship XML back without being stuffed in some ATOM-like format or their own custom half-assed re-impl of HTML complete with semantic metadata and urls that they want to call 'Resource States' because they like the sound of their own voice.
Nope. I just understand what makes REST scalable.
And so does every other persistent TCP service but you don't see Spotify or Skype failing unreliably to handle their own scalability. You don't need a single server to handle every connection, you can load balance TCP servers just like everything else.
Skype uses a P2P distributed system, it's a very different system. And yes, I see them fail to connect regularly. I don't have access to Spotify, so I can't comment on it.
Of course they can, web sockets just provide a client/server tunnel - you can cache on the server like any other RPC service. You can also cache in the browser with javascript vars or localStorage.
My university uses a proxy that caches TBs to improve performance and reduce outside traffic. Websockets don't work with it.
This makes no sense - how exactly is it less efficient when you can make the same request/response with less overhead. You can still use HTTP/SPDY for asset retrieval and web sockets for data/comms.
It's less efficient because it can't be cached. It wasn't a new argument, just an explanation of the previous.
Alright genius and which popular SPA app downloads an entire page with on-demand scripts inside? Most SPAs combine and minify most their scripts upfront and when they are fetching external .js, they're just fetching CDN-cached .js and not a '.js scripts in a REST-infected HTML page with enhanced scripts' that you seem to suggest.
Where the fuck have I suggested that? You're making up stuff. Yes, loading a single .js and then calling a REST API (asking for JSON) is a great example of a RESTful website.
By the way, "REST-infected HTML" makes no sense, unless you mean HTML shouldn't have links, because that's the only thing that can be considered RESTful.
Gmail. Heard of it?
Your Gmail must be special, since I'm on a Websockets enabled browser (FF10) and it's clearly using XHR, making dozens of HTTP calls. No Websockets to be seen on the source, anywhere.
The protocol themselves don't, but the infectious sheeps who can't ship XML back without being stuffed in some ATOM-like format or their own custom half-assed re-impl of HTML complete with semantic metadata and urls that they want to call 'Resource States' because they like the sound of their own voice.
You're making stuff up again. REST doesn't mean XML or ATOM, nor have I ever defended that. Your own blog is a perfectly RESTful service.
(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)
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?
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.
No, I refuse to believe the future is determined by some cool startup.
E.g. Gmail has history navigation and bookmarkable URIs for emails, but no such thing for chat or other page state, which is totally fine.
REST with its addressable resources has clear advantages over RPC style apps for many applications, it won't go away. Bookmarks, navigation, the overall simplicity.
One of the main practical problems is that websockets take a second or 2 to start up, clearly too slow.
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?)
http://tech.groups.yahoo.com/group/rest-discuss/message/1581...
"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.