GraphQL and REST are two common ways for applications to request data from servers. This cheat sheet helps students compare how each approach organizes requests, responses, endpoints, and data shapes. Understanding the differences is important for building APIs, choosing tools, and debugging client-server communication.
It also helps students read modern web application code with more confidence.
REST is resource-based, so clients usually request fixed URLs such as /users/42 or /posts using HTTP methods like GET, POST, PUT, PATCH, and DELETE. GraphQL is query-based, so clients send a structured query that asks for exactly the fields they need. REST often uses multiple endpoints, while GraphQL often uses one endpoint with a schema that defines available types and operations.
The best choice depends on the project, performance needs, caching strategy, team skills, and how often the data requirements change.
Key Facts
- REST models data as resources, so a URL such as /users/42 represents a specific user resource.
- GraphQL models data as a graph of typed objects, so a query can request related fields such as user { name posts { title } }.
- REST commonly uses HTTP methods with meanings: GET reads data, POST creates data, PUT replaces data, PATCH updates part of data, and DELETE removes data.
- GraphQL commonly sends queries and mutations to one endpoint such as /graphql, where query reads data and mutation changes data.
- Overfetching happens when an API returns more data than the client needs, and GraphQL reduces this by letting the client choose fields.
- Underfetching happens when one request does not return enough data, and GraphQL can reduce this by requesting related data in one query.
- A REST response shape is usually controlled by the server endpoint, while a GraphQL response shape mirrors the client query.
- GraphQL APIs depend on a schema, and a resolver function supplies the data for a field or type.
Vocabulary
- REST
- REST is an API style that organizes data around resources identified by URLs and uses standard HTTP methods.
- GraphQL
- GraphQL is a query language and API runtime that lets clients request specific fields from a typed schema.
- Endpoint
- An endpoint is a URL where a client sends an API request, such as /users or /graphql.
- Schema
- A schema defines the available types, fields, queries, and mutations in a GraphQL API.
- Resolver
- A resolver is a function that returns the data for a specific GraphQL field or operation.
- Overfetching
- Overfetching occurs when an API response includes more data than the client actually needs.
Common Mistakes to Avoid
- Assuming GraphQL is always faster than REST, which is wrong because performance depends on query design, database access, caching, and server implementation.
- Using POST for every REST action, which is wrong because REST relies on HTTP method meaning, such as GET for reading and DELETE for removing resources.
- Ignoring GraphQL query complexity, which is wrong because deeply nested queries can overload a server if limits, pagination, or cost controls are missing.
- Treating REST endpoints as random function names, which is wrong because REST URLs should represent resources such as /orders/15 rather than actions such as /getOrderNow.
- Forgetting that GraphQL still uses HTTP in many systems, which is wrong because GraphQL often travels over HTTP even though its request model differs from REST.
Practice Questions
- 1 A client needs only a user's id and email, but a REST endpoint returns id, email, address, phone, profile photo, and settings. What problem is this, and how could GraphQL reduce it?
- 2 A REST API has /users/8 and /users/8/posts. How many requests are needed to fetch user 8 and that user's posts if each endpoint must be called separately?
- 3 Write a simple GraphQL query that requests a user's name and the titles of that user's posts.
- 4 A team is building a public API with strong HTTP caching needs and stable resource shapes. Should they automatically choose GraphQL over REST? Explain the reasoning.
Understanding GraphQL vs REST Reference
An API is a contract between separate programs. The client sends a request with details such as a path, headers, credentials, and sometimes a body. The server checks the request, applies business rules, reads or changes stored data, then sends a response.
Good API design makes this contract predictable. Names should be clear, data types should be consistent, and errors should tell the client what went wrong without exposing private system details.
Validation matters at both ends. A browser form can check that an email looks valid, but the server must repeat that check because clients can send malformed or dishonest data.
REST works closely with the features built into HTTP. Status codes give useful information about a result. A successful read commonly returns a success code, a missing item returns a not found code, and an invalid request returns a client error code.
These signals help programs respond correctly without guessing from message text. HTTP caching can make repeated reads faster by allowing a browser or network cache to reuse a recent response. This is especially useful for public, rarely changing information.
Pagination is another common REST concern. A large collection should usually arrive in smaller pages, since returning thousands of records at once wastes time and memory.
In GraphQL, the schema acts like a carefully checked map of what the API can provide. Before execution, the server can reject a request that asks for a field that does not exist or uses the wrong type of input. Resolvers then do the actual work.
A resolver might read a database, call another service, or calculate a value. This flexibility has a cost. A query for many parent objects with related child objects can accidentally cause one database lookup per child group.
This is called the N plus one problem. Servers often use batching or caching inside a request to combine those lookups. They may limit query depth, query cost, or response size to prevent expensive requests.
Students often meet these ideas when a web page loads a profile, product list, comments, or dashboard data. Browser developer tools show the network requests, response bodies, timing, and status codes. Reading these details is a practical debugging skill.
Pay attention to what data the screen truly needs, how often it changes, and who is allowed to access it. Fetching less data can improve speed, but a very complex query can be hard to maintain. Security rules must apply to every requested field, not only to the main request.
The important skill is not memorizing one style as better. It is learning to trace data from a user action through the request, server logic, storage, and final display.