3 ms·
REST is an interpreted standard for stateless transactions. How do you see GraphQL as breaking what makes REST REST? If you had said HATEOS, maybe there’s somet
by IggleSniggle 8y ago
REST is an interpreted standard for stateless transactions. How do you see GraphQL as breaking what makes REST REST? If you had said HATEOS, maybe there’s something there, but GraphQL does not fundamentally break the promises of a REST transaction as far as I can tell.
- dmitriid 8y agoGood overview here: https://blog.goodapi.co/rest-vs-graphql-a-critical-review-5f77392658e7 https://blog.goodapi.co/rest-vs-graphql-a-critical-review-5f... Ok. It doesn't break all of REST's semantics and ideas. "Only" the entirety of 5.2.1 and and most of 5.3 in the dissertation
- IggleSniggle 8y agoThe author is declaring one approach to REST as the "one true way." Actually, I think the author is correct, ie pointing to a HATEOAS style REST approach. But the REST standard is interpreted. The article calls all of the RESTful APIs that are fragile in one way or another "so-called-REST." I kind of agree with that assessment of quality, but at the same time, they aren't "so-called-REST." They are actual REST. We can all just wish those were "so-called-REST" and that there was some additional mechanism to enforce "real" REST. As it stands, accusations of "that's not really REST" amount to being "No True Scotsman" arguments.