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

31–40 of 60 posts

Re: WebSockets versus REST?

#31

Post by csears »

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?

Re: WebSockets versus REST?

#32

Post by cenuij »

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 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?

Re: WebSockets versus REST?

#33

Post by mahmud »

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…

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

Re: WebSockets versus REST?

#34

Post by cenuij »

mahmud wrote: post #33
cenuij wrote: post #32

Earlier quoted context omitted.

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…

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

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

Re: WebSockets versus REST?

#35

Post by icebraining »

mythz wrote: post #28
icebraining wrote: post #20

Earlier quoted context omitted.

bidirectional RPC is much nicer than REST. 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 rea…

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.

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.

Re: WebSockets versus REST?

#36

Post by [deleted] »

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…

[deleted]

Re: WebSockets versus REST?

#37

Post by icebraining »

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…

Websockets of any reference are implentations of HTTP

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.
The rest of your post is just argument-free personal attacks, therefore I'll refrain from replying to it.

Re: WebSockets versus REST?

#38

Post by strmpnk »

mythz wrote: post #28
icebraining wrote: post #20

Earlier quoted context omitted.

bidirectional RPC is much nicer than REST. 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 rea…

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…

I don't know about "dumb clients" as it specifically talks about scriptable agents.

Re: WebSockets versus REST?

#39

Post by riobard »

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.

Post reply on HN