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 the protocol through a server over port 80. But that server can be a proxy that forwards the stream to any TCP service, on any TCP port. We're back to the days when anyone could and did develop their own protocols, and many of those became standards.
I suspect that we're going to see that kind of development again: people will initially create their own protocols to use over Websockets, then they'll recognize the benefit of tunneling existing standard TCP protocols to their Javascript programs (how about an IMAP client written in Javascript?) then finally someone will develop an HTTP client in Javascript.
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.
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).
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.
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.
Of course, this happens within a sandbox that involves initiating the connection over HTTP and tunneling the protocol through a server over port 80. But that server can be a proxy that forwards the stream to any TCP service, on any TCP port. We're back to the days when anyone could and did develop their own protocols, and many of those became standards.
I suspect that we're going to see that kind of development again: people will initially create their own protocols to use over Websockets, then they'll recognize the benefit of tunneling existing standard TCP protocols to their Javascript programs (how about an IMAP client written in Javascript?) then finally someone will develop an HTTP client in Javascript.