[jira] [Issue Comment Edited] (CASSANDRA-3380) REST Layer

["Eric Evans (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131166#comment-13131166 ] 

Eric Evans edited comment on CASSANDRA-3380 at 10/19/11 11:47 PM:
------------------------------------------------------------------

{quote}
I agree. As it stands, the elementary interface that is implemented thus far hides some of the rich types, but I would expect that we would continue to enhance the layer to provide access to those rich types and it would end up much like how SOLR exposes the underlying features and functions of Lucene via its REST interface
{quote}

How are you going to implement Cassandra's type system without implementing schema?  Once you drag schema into the mix, how will you justify this approach when it's no longer possible to plug-and-play existing systems, or drive queries with curl?

{quote}
As for demand, I think there is significant interest; enough to spawn up projects:

http://code.google.com/p/restish/
https://github.com/stinkymatt/Helena
http://www.onemanclapping.org/2010/09/restful-cassandra.html
https://github.com/gdusbabek/cassandra
{quote}

I believe the project in that first link is from Courtney Robinson, and I believe that he now advocates CQL (he started work on a CQL driver, and stopped working on that).  I'm not sure what the story is behind the second link, other than it doesn't appear to have generated much interest (based on forks and watchers).  

The last two links are both from Gary Dusbabek (a member of the Cassandra PMC).  This was a proof-of-concept that he only spent a few hours on, and one that he decided not to continue with.  It might be worth asking him why.

Honestly, I think this does more to prove why a REST interface _does not_ belong integrated in Cassandra.

----

It is not enough to simply have code.  That code needs to be maintained, and it needs more than one person who cares enough to make sure that happens.  It also needs to be documented, and supported on all the usual forums, again, something that will require a little more critical mass.

And, introducing choice can be a Good Thing, but it can also be a Bad Thing.  We need to know that this is going to be useful enough, to a large enough audience, to offset the confusion it will almost certainly generate.  Think of the people who are going to be compelled to ask which interface they should use, and who are going to have to weigh the pros and cons and then make a choice (and remember that this would bring us from 2, to 3 choices of interface).  Think of the users who are going to make assumptions about semantics or performance characteristics based on one interface or the other, only to find it's not applicable to their choice.

There is a cost associated with this, and it's fair to ask the hard questions to make ensure it's worth it.

You've also repeatedly alluded that not having this accepted as part of the project is something of a deal breaker.  Why?  Now that you have this code, doesn't it solve your particular needs?

I won't veto this if consensus is that it should be added, but I'm still not convinced that this will succeed where the other attempts have failed.  Nor am I convinced that the only way to establish success is by committing it first.  What would convince me is a moderately successful externally maintained project, with a modicum of users.

                
      was (Author: urandom):
    {quote}
I agree. As it stands, the elementary interface that is implemented thus far hides some of the rich types, but I would expect that we would continue to enhance the layer to provide access to those rich types and it would end up much like how SOLR exposes the underlying features and functions of Lucene via its REST interface
{quote}

How are you going to implement Cassandra's type system without implementing schema?  Once you drag schema into the mix, how will you justify this approach when it's no longer possible to plug-and-play existing systems, or drive queries with curl?

{quote}
As for demand, I think there is significant interest; enough to spawn up projects:

http://code.google.com/p/restish/
https://github.com/stinkymatt/Helena
http://www.onemanclapping.org/2010/09/restful-cassandra.html
https://github.com/gdusbabek/cassandra
{quote}

I believe the project in that first link is from Courtney Robinson, and I believe that he now advocates CQL (he started work on a CQL driver, and stopped working on that).  I'm not sure what the story is behind the second link, other than it doesn't appear to have generated much interest (based on forks and watchers).  

The last two links are both from Gary Dusbabek (a member of the Cassandra PMC).  This was a proof-of-concept that he only spent a few hours on, and one that he decided not to continue with.  It might be worth asking him why.

Honestly, I think this does more to prove why a REST interface _does not_ belong integrated in Cassandra.

----

It is not enough to simply have code.  That code needs to be maintained, and it needs more than one person who cares enough to make sure that happens.  It also needs to be documented, and supported on all the usual forums, again, something that will requires a little more critical mass

And, introducing choice can be a Good Thing, but it can also be a Bad Thing.  We need to know that this is going to be useful enough, to a large enough audience, to offset the confusion it will almost certainly generate.  Think of the people who are going to be compelled to ask which interface they should use, and who are going to have to weigh the pros and cons and then make a choice (and remember that this would bring us from 2, to 3 choices of interface).  Think of the users who are going to make assumptions about semantics or performance characteristics based on one interface or the other, only to find it's not applicable to their choice.

There is a cost associated with this, and it's fair to ask the hard questions to make ensure it's worth it.

You've also repeatedly alluded that not having this accepted as part of the project is something of a deal breaker.  Why?  Now that you have this code, doesn't it solve your particular needs?

I won't veto this if consensus is that it should be added, but I'm still not convinced that this will succeed where the other attempts have failed.  Nor am I convinced that the only way to establish success is by committing it first.  What would convince me is a moderately successful externally maintained project, with a modicum of users.

                  
> REST Layer 
> -----------
>
>                 Key: CASSANDRA-3380
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3380
>             Project: Cassandra
>          Issue Type: New Feature
>         Environment: Unix / Max OS X
>            Reporter: Brian ONeill
>         Attachments: trunk-3380.txt
>
>
> This is a native rest layer for Cassandra implementing AbstractCassandraDaemon.
> It uses JAX-RS fueled by Apache CXF.
> Presently it supports the following operations JSON over HTTP:
>  - Create keyspace
>  - Drop keyspace
>  - Create column family
>  - Drop column family
>  - Insert row
>  - Fetch row
>  - Delete row
>  - Insert column
>  - Delete column 
>  - Fetch column
> The patch creates a new project in contrib/rest.  You can compile the project using "ant", which uses ivy to pull in dependencies.  To get setup, you can also use the pom.xml file and m2eclipse to get it into Eclipse.
> Once compiled, simpy run "bin/rest_cassandra" and follow along in the README.txt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira