REST API / GraphQL

Rédigé par David Brulin, co-fondateur de Quai des Balises

REST API / GraphQL are two architectural styles for building APIs that let applications communicate over HTTP. REST exposes data through multiple fixed endpoints using standard HTTP methods, while GraphQL exposes a single endpoint where the client specifies exactly which fields it needs in one query.

How REST and GraphQL work

Both approaches solve the same problem — letting a front-end, mobile app, or third-party service read and write data on a server — but they structure that exchange differently.

REST (Representational State Transfer) organises an API around resources, each reachable at its own URL. Clients interact with these resources using standard HTTP methods:

GET to read data
POST to create
PUT or PATCH to update
DELETE to remove

The server decides the shape of each response. A request to /users/42 returns a predefined user object, and related data such as orders often lives at a separate endpoint like /users/42/orders.

GraphQL exposes a single endpoint backed by a typed schema that describes every available field and relationship. The client sends a query declaring exactly what it wants, and the server returns precisely that structure — no more, no less. Operations are grouped into queries (reads), mutations (writes), and subscriptions (real-time updates).

REST vs GraphQL: key differences

Criterion	REST	GraphQL
Endpoints	Multiple, one per resource	Single endpoint
Response shape	Defined by the server	Defined by the client query
Over/under-fetching	Common (fixed payloads)	Avoided (request exact fields)
Multiple resources	Often several round-trips	Combined in one query
Caching	Native via HTTP (URL-based)	Requires client-side or custom tooling
Learning curve	Low, widely understood	Higher (schema, resolvers)
Versioning	Often via /v1, /v2	Schema evolution, fields deprecated
Error handling	HTTP status codes	Errors returned in response body

The core trade-off is control versus simplicity. REST leans on the mature, cacheable HTTP infrastructure of the web; GraphQL shifts data-shaping power to the client at the cost of additional server-side tooling.

When to choose each

The right choice depends on data complexity, client diversity, and team familiarity rather than on which technology is newer.

REST tends to fit when:

Resources are simple and map cleanly to URLs (CRUD-style business apps, internal tools)
HTTP caching, CDNs, and standard monitoring matter
The API is public or consumed by partners who expect a conventional, well-documented interface
The team wants the lowest barrier to entry

GraphQL tends to fit when:

Multiple clients (web, iOS, Android) need different slices of the same data
Screens aggregate many related entities, where REST would force several calls
Bandwidth efficiency matters, particularly on mobile
The data graph is highly relational and evolves frequently

The two are not mutually exclusive. Many systems expose a REST API for public, cacheable resources and a GraphQL layer for rich internal front-ends, or place GraphQL as a gateway in front of existing REST services. For custom software, the decision should follow the consumption patterns of the applications that will actually call the API.

Questions fréquentes

No. GraphQL has grown popular for data-rich front-ends, but REST remains the dominant style for public and cacheable APIs. Both are actively used, and many architectures combine them. The choice depends on your data complexity and clients, not on one technology making the other obsolete.

Yes, and this is common. A frequent pattern is keeping REST for public or heavily cached resources while adding a GraphQL layer for internal applications that need flexible, aggregated queries. GraphQL can even sit as a gateway in front of existing REST services without rewriting them.

REST is easier to cache because each resource has a unique URL, so standard HTTP caching, CDNs, and proxies work out of the box. GraphQL typically sends all requests to one endpoint via POST, so caching usually requires client-side libraries or custom server-side strategies.

Not necessarily. GraphQL can run on the same servers, databases, and languages as a REST API; it adds a schema and resolver layer that maps queries to your existing data sources. You do not need to replace your stack, but the team must learn the schema-and-resolver model.

Building a custom software project? We design bespoke software aligned with your roadmap.

See our custom software expertise

Définitions liées

← Retour au glossaire