About the potential problems of using WebSocket:

1. Consider using a CDN

Today, web scaling involves using Content Delivery Network (CDN) front ends, not only for static content (html,css,js) but also your (JSON) application data.

Of course, you won't put all your data on your CDN cache, but in practice, a lot of common content won't change often.
I suspect that 80% of your REST resources may be cached...
Even a one minute (or 30 seconds) CDN expiration timeout may be enough to give your central server a new life, and enhance the application responsiveness a lot, since CDN can be geographically tuned...

To my knowledge, there is no WebSocket support in CDN yet, and I suspect it would never be.
The WebSocket protocol is stateful, whereas HTTP is stateless, so is designed to be cached.
In fact, to make WebSocket CDN-friendly, you may need to switch to a stateless RESTful approach... which would not be WebSocket any more.

2. Security issues

WebSocket has several potential security issues, especially about DOS attacks.
For illustration about new security vulnerabilities , see this set of slides and this webkit ticket.

Some quotes from this set of slides:

  • WebSockets still fall victim to “old” threats;
  • If you can intercept or inject you can overtake ws:/wss: (MIM attack);
  • Malicious content can exhaust browser by grabbing max. allowed number of WebSocket connections (DOS attacks on client side by browsers!);
  • Malicious content can create large number of WebSocket connections to victim WebSocket server (DOS attacks on server);
  • Just waiting for mistakes to happen (since developers can put anything on the wire);
  • wss: means secure transport, not secure app;
  • Browser support still in flux;
  • WebSockets solve connection problems, not security problems.

Furthermore, WebSocket avoid any chance of packet inspection at OSI 7 application layer level.
Application firewalls, IDS, IPS are pretty standard nowadays, in any serious security policy.
In fact, WebSocket makes the transmission obfuscated, so may become a major breach of security leak.

When to use WebSockets?

As a conclusion, I would recommend the following, for any project:

  • Use WebSocket for client notifications only (with a fallback mechanism to long-polling - there are plenty of libraries around);
  • Use RESTful / JSON for all other data, using a CDN or proxies for cache, to make it scale.

In practice, full WebSocket's applications do not scale well.
Just use WebSocket for what it was designed to: a protocol to push notifications from the server to the client.

With mORMot, and for all our end-user projects, this is the direction we are currently entitled to go.
Still privileging a pure stateless approach, which fits so good with our RESTful model. 

Discussion is welcome in our forum, as usual!