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.)
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\'...".
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).
SPDY competes with HTTP.
> 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?
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.
Not a good start :-|
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.