3 ms·

You should read about REST then :)

ajkjk 9y ago
I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless. The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.) (edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)
- mpetrovich 9y ago
  Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint. The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]: /users/123?fields=name,email,work.name,work.address where "work" is a sub-resource in the same vein as GraphQL. The difference between this and GraphQL is purely syntactic: user({ "id": 123 }) { name, email, work { name, address } } [1] http://jsonapi.org/format/#fetching-sparse-fieldsets http://jsonapi.org/format/#fetching-sparse-fieldsets
  - Touche 9y ago
    GraphQL uses a single endpoint for the entire API. It would be a POST to /graphql, there would be no /users/123 resource. GraphQL is a form of RPC, it's not REST.
  - m12k 9y ago
    When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.

I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless. The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.) (edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)

mpetrovich 9y ago
Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint. The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]: /users/123?fields=name,email,work.name,work.address where "work" is a sub-resource in the same vein as GraphQL. The difference between this and GraphQL is purely syntactic: user({ "id": 123 }) { name, email, work { name, address } } [1] http://jsonapi.org/format/#fetching-sparse-fieldsets http://jsonapi.org/format/#fetching-sparse-fieldsets
- Touche 9y ago
  GraphQL uses a single endpoint for the entire API. It would be a POST to /graphql, there would be no /users/123 resource. GraphQL is a form of RPC, it's not REST.
- m12k 9y ago
  When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.