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