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

But, if you have a multitude of different clients, or are public (therefore have no idea how the API will be used), GraphQL quickly starts to seem more appealing.

Why Not Use Both?

The biggest oddity I notice in the "GraphQL vs REST" conversation, is the falsehood that you must pick one.

In a world of SoA, you are likely to have multiple services, which expose multiple APIs. In the RPC vs REST article I point out that some services might be REST and some might be RPC, and you can absolutely throw some GraphQL in with your REST.

One mix of REST and GraphQL could just be adding a /graphql endpoint to api.whatever.com and having that as your GraphQL endpoint on an REST API.

Another, is one that has been vaguely tossed around at work, which is the idea of having one GraphQL API, acting as a gateway to our other multiple REST APIs.

Having one GraphQL server act as a sort of data proxy, giving one entry point for mixed data, one Authentication scheme despite each REST API having its own "unique" approach to tokens, one HTTP call for clients - despite it hitting multiple actual REST APIs, etc., would be a damn powerful thing.

Summary

Ask yourself - at the very least - these following questions:

How different are your clients from each other?

Do you trust your clients to handle caching?

Do you want "dumb clients" that act like crawlers - knowing very little about the API, or clients that own a lot of the logic and know a lot about the API, using it simply as a data transfer?

Are you ok letting go of HTTP debugging proxies, cache proxies, all the knowledge your team have around HTTP, etc?

Are you just doing basic CRUD with simple JSON documents, or will your API need file upload/download too?

If your REST API is following good practices, like allowing careful evolution instead of global versioning, serializing data instead of returning directly from data store, implementing sparse fieldsets to allow slimming down response sizes, GZiping contents, outlining data structures with JSON Schema, offering binary alternatives to JSON like Protobuff or BSON, etc., then the advertised advantages of GraphQL seem to fall a bit short.

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