On Tue, Oct 25, 2011 at 7:44 AM, Brian O'Neill <b...@alumni.brown.edu>wrote:
> Sasha, > > Thinking a little more about "what problem the REST API solves"... > > To be honest, I agree completely. I don't think a REST layer that provides > the same feature/function as CQL is all that valuable except in cases like I > described (which may not be all that common). Also, to be honest, I didn't > get all that excited about creating a separate project until I started > thinking about the value-added services that could be delivered with it. > (like the capabilities Riak has, etc.) > > If you think about it that way, were there any components of what you > implemented that you believe might be common needs and reusable? (e.g. you > mentioned security and policies) Did this include analytics/orchestration > at all? > > Maybe I should change the spin a bit, and focus on the "services layer" on > top of Cassandra, instead of the REST interface. That "services layer" will > deliver feature/function commonly required on top of Cassandra. (e.g. > Security) > Maybe also I should change my sign off to... "the REST bigot" ;) > > -brian > > > > On Tue, Oct 25, 2011 at 5:18 AM, Sasha Dolgy <sdo...@gmail.com> wrote: > >> Hi Brian, >> >> It's an interesting one. Hope you don't mind some feedback .....I see you >> have been making rounds publicizing the concept and patch (like on my blog >> ; ) >> http://blog.sasha.dolgy.com/2011/05/apache-cassandra-restful-api.html ) >> >> For me, and the goals I have, I'm not sure this is fit for purpose. I >> built an API that implements the business processes, business rules, >> security and policies of what I require. I made it RESTful to allow >> consumers quick and easy access.... The API implements Hector or PHPCassa >> depending on my mood. Both libraries provide an element of Connection >> Pooling, meaning I don't have to worry about that in my code. It just >> works.... The cost to me writing code that leverages Hector or PHPCassa >> isn't that high when I compare it to writing code that would leverage a >> RESTful interface. I'd have to think about Connection Pooling / selecting >> the best available node, etc. I think the cost would be higher unless it's >> a one or two node infrastructure or there is a load balancer in front of all >> of the Cassandra interfaces so that I don't have to think about it .. >> >> Would I leverage the RESTful interface if it existed with Cassandra? >> Probably not. I am happy with the libraries as they are today .. and they >> let me bundle in a bunch of fun (batch mutates, connection pooling, etc). >> They aren't overly complicated and make overall development and integration >> quite simple. >> >> I definitely think that people who are looking into Apache Cassanda for >> the first time may look for this feature and/or CQL ... and in that >> respects, it's something good to have. >> >> Probably the best question I read in the JIRA ticket ( >> https://issues.apache.org/jira/browse/CASSANDRA-3380 ) is: "...what >> problem the REST API solves..." , which is still not clear to me... >> >> -sd >> >> >> On Tue, Oct 25, 2011 at 5:48 AM, Brian ONeill <b...@alumni.brown.edu>wrote: >> >>> Peter Minearo <Peter.Minearo <at> Reardencommerce.com> writes: >>> >>> > Thrift uses RPC, I was wondering if Cassandra uses Thrift on the server >>> side to >>> > handle the requests from the clients? I know Thrift is used on the >>> client >>> > side, but what about the server side? If this is true; is there a >>> reason for >>> > it? Was a REST API with a JSON payload tried? Are there any plans to >>> > create a REST API for Cassandra? >>> >>> >>> We started work on an extension to Cassandra that would deliver a >>> REST layer. >>> >>> Check out: >>> http://tinyurl.com/3ktnc9f >>> http://code.google.com/a/apache-extras.org/p/virgil/ >>> >>> -brian >>> >> >> > > > -- > Brian ONeill > Lead Architect, Health Market Science (http://healthmarketscience.com) > mobile:215.588.6024 > blog: http://weblogs.java.net/blog/boneill42/ > blog: http://brianoneill.blogspot.com/ > > If you do not think restful API's are useful, try to make a fat client that speaks a non http or https protocol and put if on the desktops of thousands of corporate computers. Then wait for months/years for approval and firewall changes across said corporate network.