What is REST vs GraphQL?

REST in two minutes

REST — Representational State Transfer — was described by Roy Fielding in his 2000 dissertation. The core idea is that the web's existing primitives (URLs, HTTP verbs, status codes) are enough to build an application API. You name your resources (users, orders, invoices), give each one a URL (/users/42), and use HTTP verbs (GET to read, POST to create, PUT or PATCH to update, DELETE to remove). The response is usually JSON. Twenty-five years later, the overwhelming majority of public APIs are REST or REST-shaped.

GraphQL in two minutes

GraphQL was open-sourced by Facebook in 2015. The pitch: instead of the server defining endpoints, the server defines a typed schema describing all the data it can return, and the client sends queries naming exactly the fields it wants. One endpoint, flexible reads, strong typing, excellent tooling. Where REST shines on simplicity, GraphQL shines on reducing over-fetching and under-fetching in complex frontends.

A worked example

Suppose you need to render a customer dashboard showing the user's profile, their last five invoices, and the open support tickets each invoice has against it. In REST you likely make three calls: GET /me, GET /me/invoices?limit=5, and then GET /tickets?invoice_ids=... for each invoice — or you build a custom endpoint that aggregates exactly that view. In GraphQL you send one query naming user, last five invoices, and their tickets, and the server returns precisely that shape in one round trip. Same data, different choreography.

The honest tradeoffs

REST wins on operational simplicity: any HTTP client can call it, caching is straightforward with standard HTTP semantics, and third-party integrators can read the docs and be productive in minutes. It loses when you need very different shapes of data per page and your frontend ends up making seven calls to render one screen.

GraphQL wins when you have a complex frontend with many views that each need a different slice of data — you can fetch exactly what you need in one round trip. It loses on caching (no longer URL-based), on operational complexity (resolver performance, query depth limits, N+1 query problems), and on the learning curve for third parties.

At QUANT LAB

Our default for new builds is REST plus typed schemas (OpenAPI). We reach for GraphQL when the frontend has many views with very different data needs, when there is an existing GraphQL ecosystem we are plugging into, or when the team is already fluent in it. Most startups do not need GraphQL until they have a frontend complex enough to justify the operational overhead, and most never reach that point. Our API development engagements ship in whichever style fits the project.

tRPC and the third option

For teams writing both client and server in TypeScript, tRPC has become a popular third option. It avoids the REST/GraphQL debate by skipping schema definitions entirely — function calls on the server become typed client calls in the browser with no intermediate protocol. tRPC is excellent for internal APIs inside a single TypeScript codebase and a bad fit for public APIs other teams need to consume. Like every choice in this space, the right answer depends on who is calling the API and how stable the contract needs to be.