i’ll happily grant you the technical arguments…but even so, we’ve been here before, over and over: JSONPath, SPARQL, LINQ, YQL, XSLT, and even Facebook’s own dead last attempt, [FQL](https://developers.facebook.com/docs/reference/fql/). i’ve done deep dives into [YQL](https://snarfed.org/yql_yahoo_query_language_thoughts), [Azure Tables/LINQ](https://snarfed.org/windows_azure_details#Queries), [SimpleDB](https://snarfed.org/amazon_simpledb_thoughts#queries), and Facebook’s own [Data Store API](/facebook_data_store_api_thoughts#data_access), one of their earliest. i’ve even [developed one of these languages myself](https://cloud.google.com/appengine/docs/standard/python/datastore/gqlreference). i’m not proud.
they may all be technically better in various ways, but none of them have caught on broadly in the way that REST has. that may be “worse is better” at work. i guess we’ll see what the future brings.
in my own experience with Facebook’s Graph API in [granary](https://granary-demo.appspot.com/) and [Bridgy](https://brid.gy/), the main limiting factor hasn’t been the URL-path-and-query-params interface, but instead their sprawling, complicated, inconsistent data model. i haven’t needed deeply rich or complex querying, though.