GraphQL Vs REST (Part 2/3) - Sovereign Solutions

GraphQL Vs REST (Part 2/3)

 

This blog post is the second in a three part series comparing GraphQL and REST.

GraphQL Schema Vs URL ROUTES

An API isn’t useful if it isn’t predictable.  Consuming an API is typically done as part of an application or another API.  The consuming system needs to know what it can call and what it should expect to receive as the result, so that it can operate on that result.  One of the most important parts of an API is the description of what can be accessed. This is discovered when reading API documentation, and with GraphQL introspection and REST API schema systems like Swagger this information can be examined programmatically.

In REST APIs, the API is usually described as a list of endpoints:

GET /books/:id
GET /authors/:id
GET /books/:id/comments
POST /books/:id/comments

 

The shape of the API is linear, meaning there is a predefined list of things that can be accessed. When retrieving or saving data, a consumer must consider which endpoint to call.  In GraphQL, URLs are not used to identify what is available in the API. Instead, a GraphQL schema is used:

type Query {
book(id: ID!): Book
author(id: ID!): Author
}

type Mutation {
addComment(input: AddCommentInput): Comment
}

type Book { … }
type Author { … }
type Comment { … }
input AddCommentInput { … }

 

 

There is an obvious difference when compared to the REST routes for a similar data set. Instead of sending a different HTTP verb to the same URL to differentiate a read versus a write, GraphQL uses a different initial type of Mutation versus Query. In a GraphQL document, the consumer can select which type of operation to send with a keyword:

query { … }
mutation { … }

 

The fields on the Query type match up pretty nicely with the REST routes used above. That’s because this special type is the entry point into the data, so this is the most equivalent concept in GraphQL to an endpoint URL.

The way to get the initial resource from a GraphQL API is similar to REST in that a name and parameters are passed, but the main difference is what can be done from there. In GraphQL, a complex query that retrieves additional data according to relationships defined in the schema can be sent, but in REST this would have to be done via multiple requests, building the related data into the initial response, or including some special parameters in the URL to modify the response.

CONCLUSION

In REST the space of accessible data is described as a linear list of endpoints and in GraphQL it’s a schema with relationships. More specifically:

  • Similarities
    • The list of endpoints in a REST API is similar to the list of fields on the Query and Mutation types in a GraphQL API. They are both the entry points into the data.
    • Both have a way to differentiate if an API request is meant to read data or write it.
  • Differences
    • In GraphQL, a consumer can traverse from the entry point to related data, following relationships defined in the schema, in a single request. In REST, a consumer must call multiple endpoints to fetch related resources.
    • In GraphQL, there’s no difference between the fields on the Query type and the fields on any other type, except that only the query type is accessible at the root of a query. For example, a request can have arguments in any field in a query. In REST, there’s no true concept of a nested URL.
    • In REST, a consumer specifies a write operation by changing the HTTP verb from Get to Post. In GraphQL, a consumer changes a keyword in the query.

To Read Part 1 of GraphQL VS REST an Overview click here

To Read Part 3 of GraphQL VS Rest click here


Talk to our experts now to learn how Sovereign Solutions can help your organization meet its business objectives

*This content is being provided for informational and educational purposes, and should not be regarded as a specific recommendation for your situation.