4 ms·

REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query

REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query language spec. https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/ https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...

ajkjk 9y ago
That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.
- boubiyeah 9y ago
  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.
- graphememes 9y ago
  gRPC is a much better approach.
- Touche 9y ago
  GraphQL is limiting as well, just in a different way. GraphQL uses POST by default, which means you don't get browser caching. It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
- camus2 9y ago
  > REST is a (limiting) spec Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...
  - ajkjk 9y ago
    I agree that REST isn't a spec theoretically, but in my experience when you talk about building a Restful api you tend to be actually agreeing to use the HTTP verb spec, which is what I don't like at all.
boubiyeah 9y ago
Thank you, so tired to see "REST vs GraphQL" topics/blog posts. They are orthogonal.

ajkjk 9y ago

That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.

boubiyeah 9y ago
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.
graphememes 9y ago
gRPC is a much better approach.
Touche 9y ago
GraphQL is limiting as well, just in a different way. GraphQL uses POST by default, which means you don't get browser caching. It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
camus2 9y ago
> REST is a (limiting) spec Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...
- ajkjk 9y ago
  I agree that REST isn't a spec theoretically, but in my experience when you talk about building a Restful api you tend to be actually agreeing to use the HTTP verb spec, which is what I don't like at all.

boubiyeah 9y ago

Thank you, so tired to see "REST vs GraphQL" topics/blog posts. They are orthogonal.