REST and GraphQL answer the same question — how does a client get data from a server — with opposite philosophies. Understanding the difference tells you how to test each one, because the thing you are testing moves from the URL to the request body.
The core difference
With REST, the server decides the shape of each response and you call a different URL for each resource. With GraphQL, the client decides the shape and calls one URL for everything. Everything else follows from that.
| | REST | GraphQL |
| --- | --- | --- |
| Endpoints | Many URLs, one per resource | One URL for everything |
| Response shape | Fixed by the server | Chosen by the client |
| Over-fetching | Common — you take the whole object | Avoided — you ask for exact fields |
| Error signal | HTTP status code | errors array in a 200 body |
| Discovery | Documentation or OpenAPI spec | Introspection built into the endpoint |
| Caching | Simple — cache by URL | Harder — one URL, many queries |
What this changes when you test
In REST, the variation is in the URL and method. A REST test suite is a set of paths:
GET /users/42, POST /users, DELETE /users/42. You assert on the
status code first, then the body. The full loop is
in how to test a REST API.
In GraphQL, the variation is in the query. Every request goes to the same endpoint,
so your tests differ by the query body, not the URL. And the status code stops being a
useful signal — a GraphQL endpoint returns 200 even when the query failed, reporting the
problem in an errors array instead. You assert on the body every time. The details are
in how to test a GraphQL API.
When to choose REST
- The API is genuinely resource-shaped — things you create, read, update and delete.
- You want HTTP caching to do real work, keyed by URL.
- The consumers are varied and you cannot predict their needs, so a stable, documented contract beats flexibility.
When to choose GraphQL
- Clients need many related objects at once and you want to avoid a waterfall of REST calls or over-fetching whole objects.
- Different screens want different fields from the same data, and you would rather not ship a new endpoint for each.
- You value the endpoint describing itself through introspection.
Testing both without switching tools
If you run both — which is common — you do not need two tools. SchemaClient tests REST and GraphQL side by side, so collections and schema validation apply to each. Whichever style an endpoint uses, the discipline is the same: do not trust the status line, assert on the shape of what came back.