#REST APIs are REST-in-Peace APIs. Long Live #GraphQL.
▻https://medium.freecodecamp.org/rest-apis-are-rest-in-peace-apis-long-live-graphql-d412e559d8e4
With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. To do the same with a REST #API, we need to introduce unstructured parameters and conditions that are hard to manage and scale.
The biggest problem with REST APIs is the nature of multiple endpoints. These require clients to do multiple round-trips to get their data.
REST APIs are usually a collection of endpoints, where each endpoint represents a resource. So when a client needs data from multiple resources, it needs to perform multiple round-trips to a REST API to put together the data it needs.
In a REST API, there is no client request language. Clients do not have control over what data the server will return. There is no language through which they can do so. More accurately, the language available for clients is very limited.
A client can’t, for example, specify which fields to select for a record in that resource. That information is in the REST API service itself and the REST API service will always return all of the fields regardless of which ones the client actually needs. GraphQL’s term for this problem is over-fetching of information that’s not needed. It’s a waste of network and memory resources for both the client and server.
