6 ms·

> while REST is trivial. I'm not convinced of this -- or at least, we might use different definitions of "REST". The guy who created the concept of REST regul

by Twisol 6y ago

> while REST is trivial. I'm not convinced of this -- or at least, we might use different definitions of "REST". The guy who created the concept of REST regularly (or used to regularly) call out common problems with "REST" APIs that make them more like RPC APIs that happened to be built on top of HTTP. For instance, [0]. Now, just because someone created a thing doesn't mean they had it right from the get-go. (For instance, the guy who named "gif" clearly pronounces it wrong.) But I've become convinced by Roy's points about what REST ought to be, and if "REST" is going to be meaningfully distinguished from "RPC", it's probably worth understanding his position. [0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

tluyben2 6y ago
I see your point and yes, you are right. I probably would have to say that 'what people gobble together and call REST is easy to implement' and sidestep the problem that it has a lot of issues. Or maybe just that it is far easier than graphql to bolt on server-side. But yes, I agree with your comment.
- Twisol 6y ago
  Yes, sorry to pick on you specifically for that ;) In my admittedly limited experience, GraphQL is easier to get right than true REST, but obviously somewhat harder than a slapped-togther RPC API. I also like GraphQL better because if your domain fits it, it's really easy to use a GraphQL schema as a limited kind of domain model in its own right. And you can factor that schema (as well as describe proposed patches to it) with `extend type`, not unlike C#'s `partial class`.
  - tluyben2 6y ago
    I am quite enthusiastic about grapql, but the teams at my clients just stare at me like I am crazy and then go back to work. Basically everyone would rather do create /api/userswithgroupsandaclsandinvoices next to /api/users than look for other options. It's just so quick & easy to do that instead of look at other tech. I guess in companies beyond a 2 people startup team, the persons having to use the API and the persons creating it are different groups and they both are doing what is easy for them and their team. I think we would need to see a lot more server implementation and benefit tutorials for grapql to fix that issue. In the case of most of our partners and clients for instance, the API users are other companies in the same vertical; not only do the API teams not care a lot about the usage as long as it works; spending time doing something 'fashionable in the cutting edge dev world' might be nice, but no-one in their vertical will use it. They will simply ask for the 'normal API' instead.
    - Twisol 6y ago
      It's definitely hard to argue against something so easy, right? At the same time, it's often really hard for people to grasp that a solution now might have repercussions later -- and even if they do, maybe they won't be around to worry about the repercussions anyway. And if there won't be repercussions -- maybe the product is short-lived, maybe they're okay with forcing clients to upgrade every X months, maybe they rewrite the backend software regularly so cruft can't accumulate so easily -- are they wrong? GraphQL can't tell you what your problems are. I agree that there could be more resources out there, but as software engineers, we have to wrangle with the specific problem domain we're being asked to solve, and decide what the core issues are and how to tackle them. Nobody outside your team can do that for you (and I count consultants as being on your team, even if temporarily).
      - tluyben2 6y ago
        > And if there won't be repercussions -- maybe the product is short-lived Unfortunately the API's I work with are long-lived; decades. Many (but not close to most luckily) integrations are SOAP for instance. With API versioning and 'hidden' APIs (API's which are not in their normal Swagger or docs, but do exist to fix), issues like returning too much or too little is resolved, and it's fast & easy.
    - aliceryhl 6y ago
      I don't know much about GraphQL, but my instinctive reaction to it is that it seems like it has a lot of hidden consequences that I would not be able to predict in advance. For example, from what I've seen it seems like it would be easy to write queries with exponentially large responses, and that just seems dangerous to expose in an API.

by Twisol 6y ago

tluyben2 6y ago

I see your point and yes, you are right. I probably would have to say that 'what people gobble together and call REST is easy to implement' and sidestep the problem that it has a lot of issues. Or maybe just that it is far easier than graphql to bolt on server-side. But yes, I agree with your comment.

Twisol 6y ago
Yes, sorry to pick on you specifically for that ;) In my admittedly limited experience, GraphQL is easier to get right than true REST, but obviously somewhat harder than a slapped-togther RPC API. I also like GraphQL better because if your domain fits it, it's really easy to use a GraphQL schema as a limited kind of domain model in its own right. And you can factor that schema (as well as describe proposed patches to it) with `extend type`, not unlike C#'s `partial class`.
- tluyben2 6y ago
  I am quite enthusiastic about grapql, but the teams at my clients just stare at me like I am crazy and then go back to work. Basically everyone would rather do create /api/userswithgroupsandaclsandinvoices next to /api/users than look for other options. It's just so quick & easy to do that instead of look at other tech. I guess in companies beyond a 2 people startup team, the persons having to use the API and the persons creating it are different groups and they both are doing what is easy for them and their team. I think we would need to see a lot more server implementation and benefit tutorials for grapql to fix that issue. In the case of most of our partners and clients for instance, the API users are other companies in the same vertical; not only do the API teams not care a lot about the usage as long as it works; spending time doing something 'fashionable in the cutting edge dev world' might be nice, but no-one in their vertical will use it. They will simply ask for the 'normal API' instead.
  - Twisol 6y ago
    It's definitely hard to argue against something so easy, right? At the same time, it's often really hard for people to grasp that a solution now might have repercussions later -- and even if they do, maybe they won't be around to worry about the repercussions anyway. And if there won't be repercussions -- maybe the product is short-lived, maybe they're okay with forcing clients to upgrade every X months, maybe they rewrite the backend software regularly so cruft can't accumulate so easily -- are they wrong? GraphQL can't tell you what your problems are. I agree that there could be more resources out there, but as software engineers, we have to wrangle with the specific problem domain we're being asked to solve, and decide what the core issues are and how to tackle them. Nobody outside your team can do that for you (and I count consultants as being on your team, even if temporarily).
    - tluyben2 6y ago
      > And if there won't be repercussions -- maybe the product is short-lived Unfortunately the API's I work with are long-lived; decades. Many (but not close to most luckily) integrations are SOAP for instance. With API versioning and 'hidden' APIs (API's which are not in their normal Swagger or docs, but do exist to fix), issues like returning too much or too little is resolved, and it's fast & easy.
  - aliceryhl 6y ago
    I don't know much about GraphQL, but my instinctive reaction to it is that it seems like it has a lot of hidden consequences that I would not be able to predict in advance. For example, from what I've seen it seems like it would be easy to write queries with exponentially large responses, and that just seems dangerous to expose in an API.