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
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

GraphQL Devolves Power to Clients

Another question that comes up a lot for REST API developers, is:

Our iOS app, Android app and web app are very different from each other. How would we return different data for each client?

We all start off trying to make our REST APIs so generic they can be used by anything, but as the mega-include problem indicated, clients want and need a lot, and they're always trying to reduce calls.

Some basic solutions for outputting different data per-client in a REST API are:

Create custom endpoints: /iphone_snapshot. We've done this at a past company where the mobile data was completely different to anything else. It felt dirty, was almost definitely RPC, but it got the job done. Having the supposedly generic REST API know so much about a specific client defeats the purpose a little bit, but we needed to get the data to the iPhone and that was what happened.

Create custom representations: Using Content-Type: application/vnd.turtlefans.com+v1+iphone+json which had its own custom serializer would supposedly be a bit more REST in that it's just another representation, but equally odd.

Custom APIs! This concept was/is in use by Netflix if I remember rightly, and the idea is to have one API for each of their clients. There is an Android REST API, a iOS REST API, Web REST API, etc. Each of these is tailored to perfectly match the needs of their specific teams, and makes requests back to the central Generic REST API. Requiring multiple APIs, multiple development teams, etc, is certainly out of the reach of many organizations, but it does solve the issue nicely.

Or… GraphQL! Instead of making custom endpoints, custom representations, or custom APIs, the clients simply write their own queries. This moves the responsibility out of the hands of the API developers, and into the clients, who then get to write in their language of choice, instead of bugging the API team to write it in a different language.

Whether you need this paradigm shift or not is entirely up to how similar your clients are. If you're a private/internal API and your clients are all practically identical, then you certainly don't want them all handling things.

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