Spring GDS 25th Anniversary
A logistics company that ships to 190 countries built something to ship to itself.
GraphQL vs REST
What is the difference between GraphQL and REST?
GraphQL and REST are two approaches to building an API, the layer through which a frontend asks a backend for data. REST organizes everything around resources, each with its own URL. You fetch a user from one endpoint, their orders from another, each order's items from a third. GraphQL exposes a single endpoint and a schema, and the client sends a query describing exactly the data it wants, getting back that shape and nothing more.
The difference shows up most in two problems REST is prone to. Over-fetching is when an endpoint returns more fields than you need. Under-fetching is when one call is not enough and you have to make several to assemble a screen. A mobile profile page in REST might call three endpoints and throw away half of what comes back. The same page in GraphQL is one query that returns precisely the fields the screen renders, which is why bandwidth-conscious apps often favour it.
Neither wins outright. REST is simpler, leans on HTTP caching that the whole web already understands, and is easy to reason about for straightforward resource access. GraphQL gives clients flexibility and reduces round trips, but it moves complexity to the server, makes caching harder, and needs care around query cost so a single request cannot ask for too much. The right choice depends on the client, the data shape, and who is consuming the API.
GraphQL and REST at Dallonses
We do not have a house favourite. We pick based on the problem. A client building a content platform with many client types and deeply nested data got GraphQL, because the flexibility genuinely paid for its overhead and let their frontend teams move without waiting on new endpoints. Another client needed a clean, cacheable public API for partners, and REST was the obvious, honest answer. Forcing GraphQL there would have added complexity for nothing.
Both decisions are part of how we approach API-first development. We choose the style before writing the contract, weigh the caching and tooling consequences with the client, and commit to one rather than bolting on a second to paper over a bad first call. The goal is an API the client's own engineers can live with for years, not the one that reads best in a pitch.
Deciding between GraphQL and REST for a new API? Let's pick the one that fits.
Related services
Related works
Vizitio
Turning a brand into a working business.
Access Ticket
Half a million people. One app. Zero chaos.
Ready to work together?
Book a meeting
