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

Both GraphQL and REST Prefer Evolution

One false advertised benefit of GraphQL I've seen suggested (in quite a few locations) is that you "never have to version anything."

How versioning works in GraphQL. (source: http://graphql.org/)

How versioning works in GraphQL. (source: http://graphql.org/)

The suggested approach is to add new fields and deprecate old ones, which is a concept well known in REST as evolution.

Deprecating, communicating to third-parties, monitoring usage, and removing at an acceptable time, is exactly what many REST APIs have been doing forever.

Although GraphQL and REST can (and should) version via evolution just as easily, GraphQL really helps API developers out when it comes to deprecations.

GraphQL makes Deprecations Awesome

One area where GraphQL excels is to make monitoring field usage incredibly easy at a technical level. GraphQL clients are forced to specify the fields they want returned in the query:

POST /graphql HTTP/1.1

Host: localhost:3000

Content-Type: application/graphql

{

turtles(id: "123") {

length,

width,

intelligence

}

}

Tracking this would be trivial, but a REST API acts a little differently. Whilst all REST APIs make the base endpoint available via /turtles/123, not all APIs offer sparse fieldsets: /turtles/123?fields=length,width,intelligence. Of those that do offer it, it's almost always optional.

If a REST API client calls /turtles/123, then they could be using any field in that response. Imagine the API plans to get rid of intelligence (because all turtles are geniuses), how do the API developers know which clients are using that field?

An RPC approach is to make a new /getTurtle2 endpoint (or /v2/turtles/123 in a RPC API pretending to be a REST API), and tell people to use that new one.

One approach in REST APIs is to email warnings to whatever email address was entered when the client signed up for OAuth tokens (like Facebook previously did), maybe offering a feature flag so various clients can flip the switch when they are ready.

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