Another option might be the expand on the mod_shmap and mod_socache_zookeeper httpd modules I wrote a while back. The latter maintains a ZooKeeper client connection for each httpd child process – these are shared across all HTTP requests handled by the process, so (as with the code attached to this issue, I think) ephemeral nodes aren't supported, nor are ACLs, watches, etc. The code is available under the Apache license at http://people.apache.org/~chrisd/projects/shared_map/.
The shared-map module can harness a variety of "small object cache" providers to various parts of the URL namespace and then perform GET/PUT/DELETE against them. For the mod_socache_zookeeper provider these map to zoo_get(), zoo_set()/zoo_create(), and zoo_delete(). Nodes are created automatically when a PUT is made for a non-extant node.
I need to refactor mod_socache_zookeeper and create a mod_zookeeper which deals with the business of starting/stopping ZooKeeper connections for each httpd child process, something like mod_dbd does for SQL DB connections. That will allow other modules to then acquire the ZK connection and make zoo_*() requests directly; mod_socache_zookeeper and mod_slotmem_zookeeper (yet to be written) then just devolve into the business of mapping URLs to specific ZK calls.
For a REST-style interface that supported things like ACLs, sequences, stat data, etc. one could write a separate module (mod_zookeeper_rest or whatever) which supports a more complex mapping than is available through just the socache or slotmem APIs.
However the REST interface is implemented, it would be nice, I think, to use HEAD -> zoo_exists(), GET -> zoo_get(), PUT -> zoo_set()/zoo_create(), and DELETE -> zoo_delete(). There's such a natural mapping of HTTP methods to ZK methods that it would seem to call out for use, as opposed to using bags of CGI arguments to POST requests or what have you.