Interesting point of view. I've been toying with the idea of using a controlled form of SQL as a DSL for an API instead of REST routes. Since I code in Clojure,

Interesting point of view. I've been toying with the idea of using a controlled form of SQL as a DSL for an API instead of REST routes. Since I code in Clojure, I use a lib called Korma to help me build SQL queries. It has a rather good intermediary format and I started to extend it in order to support "additionnal SQL verbs and keywords". For instance, consider my home-made CONJURE BY verb. It works like INSERT but with a find-or-create-by flavor. Here is how it looks like on the client side of the api. (conjure my-record (by {:linked-record-id 1}) (values {:field "abc"})) Upon reception, it is translated into requests with classical SQL verbs (let [existing (select my-record (where {:linked-record-id 1}))] (or existing (insert my-record (values {:field "abc" :linked-record-id})))) I really did this out of curiosity, and actually this works pretty well. Once normalized in an easily parsable format (here s-expr based), it's pretty easy and straightforward to manipulate SQL: extracting where statements, merging them and reinjecting the result in a new query is actually quite easy. Want to have authorizations on what fields can be read/written by the client ? Well it's not that hard to deep-walk a query looking for unauthorized fields. Want to return data as a graph of entities like GraphQL rather than as a table or at least resolve foreign keys to the subentity they're refering to ? This should be doable. What about complex query features ? Joins, filters, conditionals and boolean combinators, limitation on the number of results, grouping, etc ... It's all already here. This leads me to wondering why are we so opaque about our abstractions ? In my view, the relational model is very useful and convenient and should be extended upon. I don't like the way GraphQL has been implemented (disclaimer: i never used GraphQL): to me it's mostly rebuilding what lies one level below although it is more general than my own proposition since it abstracts away the relational model. As for ORMs I have nothing against them. Actually with the "abstraction transparency" strategy described above, they would be a very convenient way to write a client for such an SQL-based API : it would essentially boil down to writing an adapter.