That's basically what I was going to say. I've developed a realtime system for my company that uses a REST API on the backend, but we use websockets to push updates to the clients in realtime. It's so much faster (no polling and no overhead of establishing new connections). When there's an update we hit the API once to fetch the new data and then push it out to all clients subscribed to the given data set which massively reduces load on the server.
In this approach we aren't re-establishing connections every time since the server side supports keep-alive and the clients are web browsers, which also support keep-alive.
We also hit the API once to push out changes to the subscribed clients through the connection proxy. And the next poll has relatively minimal overhead (obviously not as small as 0) to be queued back up.
In the end, though, this obviously isn't an implementation aimed at extreme efficiency. If that were the goal we'd take a much different approach.
