5 ms·

The whole idea about REST was to get rid of the complexity of SOAP webservices, custom implementations and the like by using the verbs HTTP already has and usin

by sebst 8y ago

The whole idea about REST was to get rid of the complexity of SOAP webservices, custom implementations and the like by using the verbs HTTP already has and using "speaking" URLs. The whole idea of GraphQL was actually to make complex queries easier and more performant (it's a bit like SQL for HTTP). My personal conclusion (ymmv) is to build REST APIs whenever the API should be exposed to external developers or to be integrated with 3rd party software. On the other side I like GraphQL very much, when the only (main) purpose of the API is to build the backend for a SPA.

geezerjay 8y ago
> The whole idea of GraphQL was actually to make complex queries easier and more performant (it's a bit like SQL for HTTP). How about REST's OData?
- WorldMaker 8y ago
  OData had good ideas in theory but seemed to fail in practice. Most of the biggest OData APIs [1] failed to handle denial of service attacks well. The advice I've heard is never to let OData escape the boundaries of your intranet these days. GraphQL has better mitigations for sidelining problematic queries (query names, shapes/patterns analysis tools), and doesn't start with the kitchen sink like OData did. Instead, in GraphQL you generally have to opt-in to more complex query operations, at which point you can also lock them down to explicit clients/whitelisted query names/etc while doing so. [1] NuGet's feeds being the big obvious one to mind where v1 API supported nearly the full OData query set and every version since has dropped increasingly more OData functionality for bespoke REST endpoints.
  - geezerjay 8y ago
    > Most of the biggest OData APIs [1] failed to handle denial of service attacks well. Isn't that an implementation issue? Nevertheless IIRC some OData APIs do implement anti-DoS features such as rate limiting.
    - WorldMaker 8y ago
      It can be, but I'd posit its an issue deeper in the heart of the intent and philosophy of OData (versus say GraphQL). OData looked at the basic querying monad and said "wouldn't it be great if I could do that stuff, but just you know remotely" and implemented every operation it could think of on top of that monad. It's like RPC in that way ("wouldn't it be great if function calls 'just worked' over the network?"), in that it started with some okay ideas but then accidentally ran head first into a jungle of XML encodings of security concerns orthogonal to distributed computing but deeply critical if the calling infrastructure doesn't know if the result is coming from the same processor core, the processor core next door, or a machine on a network 5000 miles away in a datacenter run by your competition. I think some of the "keep it simple stupid" principle of what REST does well that SOAP failed to do, applies between OData and GraphQL. OData did a really good job of very easily connect (via LINQ for many users) "SQL" over the wire, which is great when that's what you need. It's just that "SQL" was never optimized for that and the solutions like rate limiting have to be bolted in on top of the design, and often start to break the original appeal "'SQL' over the wire" as the subset of "SQL" that reliably works shrinks (and therewith shrinks the ability to do some of the ad hoc queries that were the draw in the first place). GraphQL doesn't entirely escape the orbit of query language as wire protocol issues, of course, but it has the benefit of having seen the issues in OData to learn from, and from what I've seen mitigates a lot of the worst cases in its opt-in approach and the fact that it looks nothing like "SQL" so it immediately doesn't inherit the assumptions of SQL and what sort of queries may or may not be immediately available.

by sebst 8y ago

geezerjay 8y ago

> The whole idea of GraphQL was actually to make complex queries easier and more performant (it's a bit like SQL for HTTP). How about REST's OData?

WorldMaker 8y ago
OData had good ideas in theory but seemed to fail in practice. Most of the biggest OData APIs [1] failed to handle denial of service attacks well. The advice I've heard is never to let OData escape the boundaries of your intranet these days. GraphQL has better mitigations for sidelining problematic queries (query names, shapes/patterns analysis tools), and doesn't start with the kitchen sink like OData did. Instead, in GraphQL you generally have to opt-in to more complex query operations, at which point you can also lock them down to explicit clients/whitelisted query names/etc while doing so. [1] NuGet's feeds being the big obvious one to mind where v1 API supported nearly the full OData query set and every version since has dropped increasingly more OData functionality for bespoke REST endpoints.
- geezerjay 8y ago
  > Most of the biggest OData APIs [1] failed to handle denial of service attacks well. Isn't that an implementation issue? Nevertheless IIRC some OData APIs do implement anti-DoS features such as rate limiting.
  - WorldMaker 8y ago
    It can be, but I'd posit its an issue deeper in the heart of the intent and philosophy of OData (versus say GraphQL). OData looked at the basic querying monad and said "wouldn't it be great if I could do that stuff, but just you know remotely" and implemented every operation it could think of on top of that monad. It's like RPC in that way ("wouldn't it be great if function calls 'just worked' over the network?"), in that it started with some okay ideas but then accidentally ran head first into a jungle of XML encodings of security concerns orthogonal to distributed computing but deeply critical if the calling infrastructure doesn't know if the result is coming from the same processor core, the processor core next door, or a machine on a network 5000 miles away in a datacenter run by your competition. I think some of the "keep it simple stupid" principle of what REST does well that SOAP failed to do, applies between OData and GraphQL. OData did a really good job of very easily connect (via LINQ for many users) "SQL" over the wire, which is great when that's what you need. It's just that "SQL" was never optimized for that and the solutions like rate limiting have to be bolted in on top of the design, and often start to break the original appeal "'SQL' over the wire" as the subset of "SQL" that reliably works shrinks (and therewith shrinks the ability to do some of the ad hoc queries that were the draw in the first place). GraphQL doesn't entirely escape the orbit of query language as wire protocol issues, of course, but it has the benefit of having seen the issues in OData to learn from, and from what I've seen mitigates a lot of the worst cases in its opt-in approach and the fact that it looks nothing like "SQL" so it immediately doesn't inherit the assumptions of SQL and what sort of queries may or may not be immediately available.