[
https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131661#comment-13131661
]
Eric Evans edited comment on CASSANDRA-3380 at 10/20/11 2:39 PM:
-----------------------------------------------------------------
{quote}
... but thinking about it, I don't think that's really a big deal unless you're
building a data browser. As an app author, you presumably already know that
user['photo'] is a blob, and as a curl user, you don't care a great deal
whether '4c330d52-5f8e-4084-918c-8dd727014ab9' is a time or a lexical uuid, or
possibly just a string that looks like one.
{quote}
A better way of stating it is, without layering schema (and the associated
client-side code), then you're forced into a world of strings. For some things
this makes no difference, for others it does. Brian's examples and use-cases
are decidedly biased toward applications that use strings everywhere.
My point was that once you resort to schema in order to make it generally
useful, then the benefits cited are moot. If your application relies on the
size of an integer, or needs access to the time component of a uuid, or uses
composite or custom types, then "speaking http + json" won't be enough to
integrate with other systems, and using curl will be a lot more involved. If
you're going to layer schema on REST, you're much better off to just use CQL.
was (Author: urandom):
{quote}
... but thinking about it, I don't think that's really a big deal unless you're
building a data browser. As an app author, you presumably already know that
user['photo'] is a blob, and as a curl user, you don't care a great deal
whether '4c330d52-5f8e-4084-918c-8dd727014ab9' is a time or a lexical uuid, or
possibly just a string that looks like one.
{quote}
A better way of stating it is, without layering schema (and the associated
client-side code), then you're forced into a world of strings. For some things
this makes no difference, for others it does. Brian's examples and use-cases
are decidedly biased toward applications that use strings everywhere.
My point was that once you resort to schema in order to make it generally
useful, then then the benefits cited are moot. If your application relies on
the size of an integer, or needs access to the time component of a uuid, or
uses composite or custom types, then "speaking http + json" won't be enough to
integrate with other systems, and using curl will be a lot more involved. If
you're going to layer schema on REST, you're much better off to just use CQL.
> 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
