2 ms·

This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You c

This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You could pretty much make a terribly designed system in a similar way with GraphQL except maybe less accidentally cause it imposes some constraints on the developer to follow what the library gives you. The benefit of GraphQL is the fact that there's very few ways of implementing it

slver 5y ago
So it's unnecessarily antagonistic, but then you proceed to agree with everything I said. Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way. GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it". The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine). When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API. No, GraphQL can't compete with that definition of REST. But also it's not trying to.