3 ms·
> GraphQL is an ORM for rest apis No, GraphQL is a protocol that replaces REST. Its closest analogue is the unholy beast that is SOAP + WSDL, except without t
by lobster_johnson 11y ago
> GraphQL is an ORM for rest apis
No, GraphQL is a protocol that replaces REST.
Its closest analogue is the unholy beast that is SOAP + WSDL, except without the insanity of XML. With SOAP/WSDL you declare a schema for your API, which then accepts API calls containing parameters. SOAP/WSDL follows a classical RPC paradigm where you execute functions that take positional arguments.
GraphQL dispenses with that terminology, but is still very much RPCish. A key difference is that "arguments" are keyword-based. Where SOAP/WSDL would have you pass a "complex type" (ie., a struct) with optional fields, in GraphQL everything is built out of structs. Another key difference is that the output follows the structure of the input.
GraphQL remaps REST's paths to nested keys. For example, given the routes:
/books
/books/:id
/books/:id/authors
This becomes:
query {
book(id: ...) {
authors
}
}
Where REST doesn't help you is when you want to be able to filter on a lot of things — either your API becomes an explosion of all permutations of relationships, or you do (as many do) create a "query API" that takes all sorts of criteria as inputs. For example: When you get a books' authors you might want to filter by editors only. Or you want to find all books written by an author that were published in the 1950s. REST also doesn't help the client pick which fields to include, or which relationships to follow. Sure, you can implement it on top of REST, but any such solution becomes ad-hoc and app-specific.
Part of that is, firstly, because REST is a set of rules, not a complete protocol, and secondly, REST wants to deal with resources, not queries. Queries (ie., POST to some collection) are left as an exercise for the reader.
Coincidentally, there is no reason why you can't encode GraphQL queries as GET URLs via paths:
/books/id=1/year=1950..1959/authors/name=~John
This probably violates the tenets of REST, which says that resource URLs should uniquely identify a resource. I forget what REST says, if anything, about "views" into resources.