Hacker News new | ask | show | jobs
by DiabloD3 2891 days ago
The problem with REST is largely the people who look at it blindly as "thing that makes the CRUD go" instead of as a methodology of how to effectively use HTTP verbs and designing URIs that make sense.

So I guess my question is, why would I use GraphQL over, say, the Swagger tool suite? Swagger and the OpenAPI spec defines a way of doing REST that best fits both what Roy Fielding meant for REST but also fits IDE and tool automation systems.
1 comments
jaegerpicker 2891 days ago
There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more. GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

link
krainboltgreene 2891 days ago
> There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more.

That's not a unique benefit of GraphQL. Any HTTP based API can do this, regardless of how it's designed.

Some specifications even have it baked in (See: jsonapi.org).

> GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

Again, not unique to GraphQL.

> There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

Again...

link
clintonb 2891 days ago
> There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

Assuming you are using some from of Semantic Versioning, adding a field to a REST API should never break existing clients. Did you mean "removing" a field?

link