GraphQL vs REST: обзор

Phil Sturgeon, “GraphQL vs REST: Overview”, public translation into English from English More about this translation.

Translate into another language.

Participants

Big_Shark 82 points
atygaev.mi 16 points
Join Translated.by to translate! If you already have a Translated.by account, please sign in.
If you do not want to register an account, you can sign in with OpenID.
Pages: previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9 10

Another approach would be to create a new version of the resource, meaning instead of calling GET with Accept: application/vnd.turtlefans.com+v1+json they should start calling with Accept: application/vnd.turtlefans.com+v2+json.

All of the above approaches suffer the same issue, and that is that an entire version can be overkill for a simple change, and you might be forcing the developers to look into a version upgrade without needing to.

For example, if the client is requesting application/vnd.turtlefans.com+v1+json and the API is removing intelligence in v2, the API developers know not to drop v1 until the last of the clients are upgraded. Sadly, if clients are calling v1 but not using the intelligence field, the API developers have no idea! The API developers only know that the clients want v1, not what they're using of that v1 resource.

GraphQL makes it easy to track specific field usage to a client, meaning API owners can reach out to only those clients using fields that are heading out, or for internal projects you could have errors thrown in development/staging environments. I had a vague brain fart about doing this latter option for non-GraphQL HTTP APIs, but have not had a chance to see it through yet.

That could help in some situations, but would certainly be baked into things the same way it is in GraphQL.

GraphQL making field deprecation easier was a point brought to my attention by Tom Clark, super-smart Head of Devops at WeWork.

GraphQL Puts Client Performance First

GraphQL is always the smallest possible request, whilst REST generally defaults to the fullest. It's common practice to offer options like ?fields=foo,bar or partials. Google recommend doing this for HTTP APIs, whatever that's worth.

Even if a REST API returns only a basic partial by default, there are still more bits being transferred over the wire by default, than with the GraphQL approach. If a client needs a field, they request it, and if the API adds a new field, clients don't get it, unless they discover that field in a blog post or whatever and add it to the GraphQL query.

Pages: previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9 10