A Comparison between GraphQL vs REST API

If you search for API terminology, you will find out that it is some sort of communication between your application and the server for various requests made by the users. You can send some http request from some client whether that is a web page or mobile app then that means we have a web service which exposes certain entry points where clients can fetch or send data. To build this kind of web service then you basically follow one of these approaches. You either build a REST API and use the concepts related to that or you follow GraphQL API approach and build your web service according to it.

The way that you build the web service reflects the way that the client uses that service based on your queries.

REST APIs are comprised of data entities that stay on the URL’s on a server. When a request is received the API responds with the full data payload of that entity.
When it comes to REST API, the concept is that it is comprised of multiple endpoints of multiple URL’s otherwise paths that belong to the domain where you host the web service. The web service reacts to different HTTP requests made by the client.
GraphQL was invented by Facebook. It works with only one endpoint which always is reached with a POST request and you can name it whatever you want but often is yourdomain.com/graphql. So, this is a crucial difference as it takes one endpoint for all requests, whether the REST API takes multiple endpoints for the different requests.
In both API’s you typically exchange data and you may also send back binary data from both of them.
You can use any server-side language and framework when working with a REST API or GraphQL API.
Both of them are stateless, meaning that servers do not store session state and that every client request is treated independently. You don’t see session-based authentication approaches being used there because you don’t store any data for the client on the backend there. You just expose these endpoints and whoever sends the right kind of request combined with some authentication rules gets the data depending on what you expose on your API.
The way that you send requests to them differs as REST API offers URL requests and GraphQL offers queries. In REST API you have an http verb, the path or URL and the request body you need to attach, however not all requests need a body response, for example GET request doesn’t include a body. It’s up to you to define which paths or endpoint you will use according to your application needs.
For the GraphQL API there is one endpoint and that endpoint can have any path you want. Often it is /graphql and it always takes a POST request, then you state what you want in the request body. Therefore, the HTTP verb must be POST and the path must be /graphql as it is always fixed and the only thing needed to change is the body that contains GraphQL query which is parsed and encoded in the backend. Except, that GraphQL doesn’t communicate with the database but with the web service which does the parsing and runs it. Therefore, you could represent the data in your application with a graph of nodes and edges. The nodes represent objects and the edges represent relationships between these objects.
A GraphQL query consists of an operation type (query) which you specify, there you have three important types, which means you have to query for some data to get some response. Also, there are mutations and subscriptions which means with mutation you want to edit some data, store new data or add existing data on the server. With a subscription you want to set up a live subscription so that the server actively informs you about changes that happened there. Now this would be not possible over HTTP protocol and for that you will need websockets instead. So, a GraphQL query works this way: you give the operation type an endpoint or an identifier which helps the server to understand with which resource you want to work and of course you can’t send any arbitrary queries.

• Flexible
• URL Requests
• Supports GET, POST, PUT, PATCH, DELETE
• Database communication

• One single endpoint
• Communicates with the web service
• Returns JSON response
• Comprised of types

When using REST API approach, you might need multiple entities at one time in which case each request is under fetching the actual data we want. In other cases, you may want only a specific set of the entities. Therefore, if you need two or more resources, you would need to make separate requests to two endpoints. Instead of multiple url’s a /graphql API has a single entry point where data is queried or fetched by describing it with a syntax that mirrors its return shape in JSON. The syntax can work with any programming language.
In the end, it comes down to your personal preferences or to your experience to choose and pick the right API for your project.