Hacker News Reader

The bigger picture is that WebSockets increases what's possible via the web. In theory REST isn't tied to HTTP although practically speaking, the two do go hand in hand. The natural REST application is also somewhat different from the natural WebSocket application.

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

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

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

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

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.

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?

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

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.

He was right. Who are you exactly?