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
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?
As for demand, I think there is significant interest; enough to spawn up projects:
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.