I wrote an HTTP server (
https://github.com/tom-seddon/yhs) with pretty much exactly this use case in mind. (This influenced the main unusual thing about it: it doesn't use threads, the idea being that when your function is called in response to an HTTP request, you're less likely to have to do anything special before modifying values as requested.)
The code is mostly complete, and should be usable as-is, but I never ended up using it in anger. My quick and dirty stopgap solution at the time was some on-screen (on the iPhone) widgets, and people seemed to prefer that in the end, because it meant they didn't need a computer/second iPhone/etc. So I never rolled out an HTTP-based equivalent.
If I were doing it again, I probably wouldn't bother with a full(ish) HTTP implementation - I'd support only WebSockets. Then write the Javascript client code separately from the game, and store it separately in SVN or whatever. Faster iteration on the client code, and you can update the UI stuff separately from the game.
Though of course, if people preferred on-screen widgets once, they might then still prefer it a second time ;)
(As an example, a project that's on my must-take-a-closer-look list, that I believe but works in the way I suggest: https://github.com/Celtoys/Remotery)