REST has issues for end users. They will still have to write clients and do a lot of extra work. REST support is good in most languages but having native support is superior. That’s why I choose Thrift for the CuratorRPC Proxy.
-Jordan On April 10, 2015 at 9:32:47 PM, Michi Mutsuzaki ([email protected]) wrote: Yeah it's quite painful to manage another set of processes just for proxying requests. I'd definitely use this if I can run it embedded in the ZooKeeper process. I'm very excited about the idea of being able to use curl to look at what's in ZooKeeper :) On Fri, Apr 10, 2015 at 6:03 PM, Patrick Hunt <[email protected]> wrote: > Here's the spec and readme from contrib/rest: > > http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/SPEC.txt?view=markup > > http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/README.txt?view=markup > > > The current implementation is a standalone proxy. It's not embedded in zk > itself. That might be part of the reason. > > Patrick > > On Fri, Apr 10, 2015 at 4:43 PM, Camille Fournier <[email protected]> > wrote: > >> Forgive me for not reading the code, can you share in more detail what the >> existing REST proxy provides? I'm curious why people are jumping to use >> etcd because of ease of use w/http access if we already have something that >> works? >> >> On Fri, Apr 10, 2015 at 7:28 PM, Patrick Hunt <[email protected]> wrote: >> >> > There's the REST work in contrib. Both Andrei and I worked on that - I >> did >> > the basic support and Andrei added sessions and heartbeating among other >> > improvements. >> > >> > Now that 3.5 has embedded Jetty it should be much simpler to run REST as >> > part of the ZK service itself. When the original proxy work was done >> Jetty >> > was not yet part of ZK. >> > >> > Patrick >> > >> > On Thu, Apr 9, 2015 at 10:20 AM, Jordan Zimmerman < >> > [email protected]> wrote: >> > >> >> Since Curator is now Apache and I'm no longer at Netflix, I don't follow >> >> Netflix messages very much. Sorry about that. >> >> >> >> -Jordan >> >> >> >> >> >> >> >> On April 9, 2015 at 12:15:02 PM, Camille Fournier ([email protected]) >> >> wrote: >> >> >> >> Thanks Jordan! I actually asked on Twitter whether Netflix had anything >> >> but >> >> didn't get a clear answer. >> >> >> >> On Thu, Apr 9, 2015 at 11:22 AM, Jordan Zimmerman < >> >> [email protected]> wrote: >> >> >> >> > FYI >> >> > >> >> > Curator now has a Thrift-based proxy that has all the ZK APIs exposed >> as >> >> > well as Curator's added APIs and recipes: >> >> > >> >> > http://curator.apache.org/curator-x-rpc/index.html >> >> > >> >> > -Jordan >> >> > >> >> > On April 8, 2015 at 2:09:33 PM, Camille Fournier ([email protected]) >> >> > wrote: >> >> > >> >> > All, >> >> > >> >> > I've been doing a bit of research on etcd as part of work for an >> >> upcoming >> >> > talk, and it has gotten me thinking about what it would take to create >> >> an >> >> > http version of ZK for certain operations. For many operations you >> could >> >> > put an http proxy in front of ZK to translate, even implementing the >> >> > "long-poll-style" watch operation to some extent. But it would be very >> >> > hard >> >> > to do a temporary node via a proxy without a lot of proxy failover >> >> > complexity. >> >> > >> >> > As a bit of background, if you want to do an "ephemeral" node in etcd, >> >> you >> >> > basically create a key with a TTL. Unless the key is updated with a >> new >> >> > TTL, the key will auto-expire when the TTL is reached. Now, I have a >> lot >> >> > of >> >> > thoughts about this (seems like you have to implement heartbeats via >> >> http >> >> > to truly mimic ephemeral nodes which may not be as simple as all this >> >> http >> >> > sounds), but I do think that if there is appetite for easy http access >> >> for >> >> > consensus systems we should at least take the time to think about what >> >> it >> >> > would take for us to provide this. In particular, I think we'd have to >> >> > make >> >> > it possible to create a node with a TTL that is not tied to a >> particular >> >> > session. >> >> > >> >> > Curious to see if anyone has any thoughts on this. It seems like a bit >> >> of >> >> > a >> >> > shame that ZK, which is a good battle-tested system, is frequently >> being >> >> > passed-over these days because of the complexity of clients, and the >> >> fact >> >> > that it is really pretty damn hard to do a client impl in certain >> >> > languages >> >> > (Ruby is the notable one I've heard). >> >> > >> >> > Best, >> >> > C >> >> > >> >> > >> >> >> > >> > >>
