Your proposed solution sounds like long polling, which could work really well.
You would request /game/17/move/5 and the server will not send any data, until move 5 has been completed. If the connection drops, or you get a time-out, you simply reconnect until you get a valid response.
The benefit of this is it’s very quick – as soon as the server has new data, the client will get it. It’s also resilient to dropped connections, and works if the client is disconnected for a while (you could request /game/17/move/5 an hour after it’s been moved and get the data instantly, then move onto move/6/ and so on)
The issue with long polling is each “poll” ties up a server thread, which quickly breaks servers like Apache (as it runs out of worker-threads, so can’t accept other requests). You need a specialised web-server to serve the long-polling requests.. The Python module twisted (an “an event-driven networking engine”) is great for this, but it’s more work than regular polling..
In answer to your comment about Jetty/Tomcat, I don’t have any experience with Java, but it seems they both use a similar pool-of-worker-threads system to Apache, so it will have that same problem. I did find this post which seems to address exactly this problem (for Tomcat)