Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebSockets versus REST?

infoq.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: WebSockets versus REST?

#41

Post by 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...

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

Re: WebSockets versus REST?

#42

Post by javascriptlol »

DougWebb wrote: post #23

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 th…

Unfortunately, there will be no UDP protocols. So we're not quite back to where we were in 1970 yet.

Re: WebSockets versus REST?

#43

Post by almost »

csears wrote: post #31
almost wrote: post #10

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)

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 :)

Re: WebSockets versus REST?

#44

Post by greggman »

javascriptlol wrote: post #6
andrewvc wrote: post #2

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.

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

On the one hand there are tons off applications that don't need UDP and will do just fine with WebSockets. Lots of AJAX based sites can be made much more responsive through WebSockets. Email sites, sites like Google Docs, etc. Chat sites like Meebo or Google Talk. Even many types of games will do just fine with WebSockets. A WoW style game, a Diablo style game, etc.

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.

Re: WebSockets versus REST?

#45

Post by javascriptlol »

greggman wrote: post #44
javascriptlol wrote: post #6

Earlier quoted context omitted.

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

On the one hand there are tons off applications that don't need UDP and will do just fine with WebSockets. Lots of AJAX based sites can be made much more responsive through WebSockets. Email sites, sites like Google Docs, etc. Chat sites like Meebo or Google Talk. Even many types of games will do just fine with WebSockets. A WoW style game, a Diablo style game, etc. On the other hand they, the w3c and the browser ven…

Thanks! I didn't know about WebRTC, so this seems like good news. Is it tailored to video/audio or are we talking about something you can design a protocol on top of?

Re: WebSockets versus REST?

#46

Post by 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?)

Re: WebSockets versus REST?

#47

Post by ypcx »

DougWebb wrote: post #23

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 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. Function calls will be RPC over WebSocket. The much-less-than 1% users without WebSocket or Flash support (which implements a fallback WebSocket client), or with a Flash or WebSocket behind a Proxy that won't let these through, will be defaulted to the low-level website, which has to be there anyway, because dynamic content is very badly indexable by search engines. I think I will be working on a Node.js micro-framework to accomplish this very soon. This of course will have to be backed by a fast in-memory database with pub-sub, like Redis. The other fallback transports for WebSocket, like JSONP or other hacks, aren't in my opinion worth it at all, given the proliferation of Flash and WebSocket-supporting browsers.

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

Re: WebSockets versus REST?

#48

Post by intranation »

hengli wrote: post #7

http://stackoverflow.com/questions/6806263/websocket-api-to-... One of the main practical problems is that websockets take a second or 2 to start up, clearly too slow.

WebSockets don't have much startup time at all really. If you're using Socket.io or another Flash-based abstraction you can expect long lead/start up times due to the Flash policy file, but plain old WebSockets should be as fast as any other TCP connection.

Re: WebSockets versus REST?

#49

Post by beaumartinez »

riobard wrote: post #39
DougWebb wrote: post #23

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 th…

No, WebSockets doesn't complete with HTTP. It complements HTTP. SPDY competes with HTTP.

No, SPDY competes with TCP[1].

[1] http://www.chromium.org/spdy/spdy-whitepaper

Re: WebSockets versus REST?

#50

Post by danssig »

cenuij wrote: post #32
DougWebb wrote: post #23

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 th…

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 t…

He was right. Who are you exactly?
Post reply on HN