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.
WebSockets versus REST?
51–60 of 60 posts
Re: WebSockets versus REST?
#52Earlier quoted context omitted.
They don't throw it away, they just don't add the unnecessary cruft and overhead to get their stellar latency and response times. 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 tu…
They don't throw it away 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…
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.
Re: WebSockets versus REST?
#53None 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.
Re: WebSockets versus REST?
#54Earlier quoted context omitted.
They don't throw it away 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…
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 unreli…
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.
Re: WebSockets versus REST?
#55Earlier quoted context omitted.
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?
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 :)
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.
Re: WebSockets versus REST?
#56I 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 th…
Unfortunately, there will be no UDP protocols. So we're not quite back to where we were in 1970 yet.
UDP will be coming as a part of the WebRTC effort. The current spec draft and prototypes don't include arbitary data channels, but they are currently being specced on the mailing list.
Re: WebSockets versus REST?
#57I 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 th…
I think it does compete with REST. I want my framework as simple as possible (and real-time as possible, of course), and I know that to reach 100% of the audience plus have a good SEO, I will certainly have to have 2 versions of my website: One low-tech, no-javascript, pure HTML 4. The other, thanks to the first one, can shoot very high. So I will get rid of REST, and have all my data being synchronized via WebSocket…
Yes, ok, you will use WebSockets for your API. But what will it look like to book a ticket on your API? "{'action': 'book', 'from': 'Chicago', 'to': 'Moscow'}"? It's still junk without REST style.
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\'...".
Re: WebSockets versus REST?
#58Earlier quoted context omitted.
I think it does compete with REST. I want my framework as simple as possible (and real-time as possible, of course), and I know that to reach 100% of the audience plus have a good SEO, I will certainly have to have 2 versions of my website: One low-tech, no-javascript, pure HTML 4. The other, thanks to the first one, can shoot very high. So I will get rid of REST, and have all my data being synchronized via WebSocket…
Yes, ok, you will use WebSockets for your API. But what will it look like to book a ticket on your API? "{'action': 'book', 'from': 'Chicago', 'to': 'Moscow'}"? It's still junk without REST style. 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…
(maybe the examples I provided are not ugly enough to show difference, so I'll try to do that here)
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/ and that only operations are CRUD on either all users -> /users/ or on concrete user /users/. That gives so much more clarity (+ caching reads, + only open transactions on POST/PUT/DELETE).
Re: WebSockets versus REST?
#59Earlier quoted context omitted.
Unfortunately, there will be no UDP protocols. So we're not quite back to where we were in 1970 yet.
UDP will be coming as a part of the WebRTC effort. The current spec draft and prototypes don't include arbitary data channels, but they are currently being specced on the mailing list.
Excellent. Someone else pointed this out. This is good news.
Re: WebSockets versus REST?
#60Earlier quoted context omitted.
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 :)
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.
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 :)