Card 01/ 09
Three API Styles: Resources, Queries and Procedures
REST exposes things to act on, GraphQL a graph to query, and gRPC functions to call.
An API style is the model a client uses to ask for something. REST exposes resources at URLs and acts on them with HTTP methods. GraphQL exposes one endpoint and a schema of types, and the client sends a query naming the fields it wants. gRPC exposes procedures, functions with typed inputs and outputs, that a client calls as if they were local. All three usually run over HTTP.
| Style | What it exposes | One call | Data format |
|---|---|---|---|
| REST | Resources at URLs, acted on by methods | GET /orders/7 | Usually JSON |
| GraphQL | One endpoint and a typed schema the client queries | POST /graphql with a query for order 7's id and status | JSON |
| gRPC | Procedures defined in a .proto file | OrderService.GetOrder with order_id 7 | Protocol Buffers, a binary format |
It helps to picture three ways of buying groceries. REST is a shop with labelled shelves: you go to each shelf for what it holds. GraphQL is a personal shopper given a list, who brings back exactly what is on it. gRPC is a phone order on a fixed form, quick and precise, with every field agreed in advance. The comparison breaks on cost: a shopper sees how heavy a list is, while a GraphQL server does not know what a query will cost until it measures it.
What stays the same. Every style still needs authentication, authorisation, validation, rate limits, errors a client can act on, and a plan for evolving. The style changes how a request is shaped, not what makes an API safe.
What differs. Who chooses the shape of the response, whether HTTP caches can understand the traffic, how strongly the contract is typed, and which clients can call it, especially browsers.
So the question is never which style is best, but which fits the clients of this integration.
← → move through sections and cards