GraphQL vs REST

When you talk about API design, the first thing that probably comes to mind is Representational State Transfer (REST). A standard for data retrieval from the server, it’s based on accessing data by URLs.

In 2000, when REST was developed, client applications were relatively simple, development pace wasn’t nearly where it is today, and, as a result, REST was a good fit for many applications. REST gave us important concepts for API design – stateless servers and structured access to resources. However, since that time APIs have gotten more complex and data-driven affected by the following factors:

• Increased mobile usage created a need for more efficient data loading.
• A variety of different clients: REST makes it difficult to build an API that satisfies their needs, as it returns a fixed data structure.
• Expectations for faster feature development: To make a change on the client side in REST, often we have to adjust the server side to support it, which slows product iterations.

GraphQL, a modern alternative to the REST-based architecture, aims at solving its shortcomings. Unlike REST, GraphQL allows for requesting specific data that a client needs, departing from the fixed data structure approach.

This article introduces the GraphQL toolset and its key features; elaborates on how GraphQL is taking API design architecture to a new level, and in what ways it is still losing to REST.

 

Based on the graph data modeling with the schema at its core, GraphQL has three primary operations:

1. Query for reading data
2. Mutation for writing data
3. Subscription for automatically receiving real-time data over time.