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.
You seem to be infected with the mindset that you can only develop scalable and high-performance cached services with REST - you really need to step outside of your comfort zone.
>> 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.
You seem to be infected with the mindset that you can only develop scalable and high-performance cached services with REST - you really need to step outside of your comfort zone.
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.
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.