Interesting, another use of a SQL-like language as the query language for a data store that's definitely not an SQL database. (YQL is another example.) I really don't understand why ORMs always seem to want to create their an object-based query language--SQL is just fine for querying.
Interesting. Isn't this the metalinguistic paradigm in action? Ie instead of creating a library/API you create a whole new Domain-Specific Language.<p>Thoughts on this? Is there room for innovation in APIs via DSLs?
Anyone who implements this might want to bear in mind that you will have created a very chatty backend based on JSON calls.<p>It should be fairly obvious that you're quite likely to now have pain points in serialising and deserialising that much JSON.<p>It seems to me that you now have 2 choices:<p>1) You forget this approach and instead perform REST composition and aggregation by adding a datastore in the composition/aggregation service to reduce the number of calls to the back end.<p>2) You ditch the internal REST services and change to using protocol buffers or something else to remove the JSON bottle neck internally.<p>Either of which will make ql.io redundent.<p>ql.io appears to be trying to solve REST as the language of enterprise services, without using a service bus or BPEL to aid with composition or aggregation.<p>I agree there is a problem space here, and whilst I have an immense amount of respect for Subbu (worked on ql.io, authored REST book) I'm unconvinced that this approach is the solution to the problem.
Ah, looks like this is the library Subbu Allamaraju refers to at <a href="http://www.subbu.org/blog/2011/11/apis-are-a-pain--the" rel="nofollow">http://www.subbu.org/blog/2011/11/apis-are-a-pain--the</a> aim of ql.io is to alleviate the challenges of "aggregation, parallelization, and orchestration of forks and joins." (i.e. in practice, "consistent RESTful APIs don’t matter as much as we think," nice though they may be.)
I've been thinking lately that certain APIs would benefit from two distinct 'entry points':<p>1. a nice, object-oriented hierarchical RESTful interface for standard queries and getting started e.g. /api/user/12345/friends/<p>2. a sql-esque query language interface for arbitrary, complicated requests e.g. /api/?q=select id from users where name="Joe"<p>It looks like ql.io could be a good way to provide the latter.
This looks a lot like OData... strange that they don't mention it when they compare themselves to other querying technologies on the 'about' page.<p><a href="http://www.odata.org/" rel="nofollow">http://www.odata.org/</a>