Though, queries are distinct from relations. They are a database concept, existing before Codd's relations and also present in NoSQL etc.
I was thinking of the relational concepts that SQL builds on. A way to separate these concepts is to do the query in two stages: (1) a relational transformation over the database that denormalises it (joining lists) into a list containing your answer; (2) a query to extract that answer. (These two stages are usually redundant; it's just a way to think about it, not how to write the query, nor for a DB to implement it.)
In a sense, the nesting of REST APIs means they are heavily de-normalised: to access some data, you have to start at the top and work your way down that "path". They sometimes have multiple paths to the same data, each one representing a different denormalisation. The reason this is not "relational" is because you can only use pre-existing paths; you can't make up your own as needed.
It's only in a narrow sense that REST APIs are normalised, in that you can only return one list, with no joins in it.
BTW: A query returns a subset of the database. It seems sensible to return only the subset needed. But there's an odd trade-off in REST: caching more than a specific query needs is more likely to be useful for the next query (in effect, it distributes the database over network caches). Bandwidth is plentiful, so let's return 10KB instead of 10 bytes. But latency is a problem (IMHO); presently, we need several requests to get the data we want.
I just had an idea: a rich REST API query language (as you say), and also have a client-side query language, and a client-side optimisation engine that transforms each query into a form that maximises cache hits. e.g. get much more information than needed, if it happens to be cached nearby. It is like the query optimisations that databases presently use, but on the client, on the other side of the expensive network.
You could also over-request, to populate the cache for future queries (your own and from other users). This might need a lot of tuning, based on actual usage patterns between users. Existing web-caching experience might guide this.
Finally: at the moment, I think it's clearly true that different ways of accessing the same data are not that important. Perhaps they'll never be, for web-data that is always used in the same way. The "enterprise" needed relations because they have heaps of apps using centralised data in different ways (manufacturing, inventory, sales, analysis, etc). However, as the enterprise moves into the cloud, and as developers start to construct services out of services (with much deeper integration than a simple mash-up; more like using remote libraries), this will become extremely important to some users.
whoa, long post. just trying to get my thoughts in order. hope it's of some use.
Though, queries are distinct from relations. They are a database concept, existing before Codd's relations and also present in NoSQL etc.
I was thinking of the relational concepts that SQL builds on. A way to separate these concepts is to do the query in two stages: (1) a relational transformation over the database that denormalises it (joining lists) into a list containing your answer; (2) a query to extract that answer. (These two stages are usually redundant; it's just a way to think about it, not how to write the query, nor for a DB to implement it.)
In a sense, the nesting of REST APIs means they are heavily de-normalised: to access some data, you have to start at the top and work your way down that "path". They sometimes have multiple paths to the same data, each one representing a different denormalisation. The reason this is not "relational" is because you can only use pre-existing paths; you can't make up your own as needed.
It's only in a narrow sense that REST APIs are normalised, in that you can only return one list, with no joins in it.
Looking at WCF Data Services http://en.wikipedia.org/wiki/WCF_Data_Services, those examples aren't (necessarily) relational, just queries, in that there is no transformation, just selection of a sublist. It's not fair to judge it on one example though. I found another eg http://msdn.microsoft.com/en-us/library/dd728279.aspx it's analogous. Maybe I'll read the specs in detail later. :-)
BTW: A query returns a subset of the database. It seems sensible to return only the subset needed. But there's an odd trade-off in REST: caching more than a specific query needs is more likely to be useful for the next query (in effect, it distributes the database over network caches). Bandwidth is plentiful, so let's return 10KB instead of 10 bytes. But latency is a problem (IMHO); presently, we need several requests to get the data we want.
I just had an idea: a rich REST API query language (as you say), and also have a client-side query language, and a client-side optimisation engine that transforms each query into a form that maximises cache hits. e.g. get much more information than needed, if it happens to be cached nearby. It is like the query optimisations that databases presently use, but on the client, on the other side of the expensive network.
You could also over-request, to populate the cache for future queries (your own and from other users). This might need a lot of tuning, based on actual usage patterns between users. Existing web-caching experience might guide this.
Finally: at the moment, I think it's clearly true that different ways of accessing the same data are not that important. Perhaps they'll never be, for web-data that is always used in the same way. The "enterprise" needed relations because they have heaps of apps using centralised data in different ways (manufacturing, inventory, sales, analysis, etc). However, as the enterprise moves into the cloud, and as developers start to construct services out of services (with much deeper integration than a simple mash-up; more like using remote libraries), this will become extremely important to some users.
whoa, long post. just trying to get my thoughts in order. hope it's of some use.