REST vs gRPC vs GraphQL
·
REST, GraphQL and gRPC are three styles for building an API. REST organizes an API around resources at URLs and uses HTTP methods on them; GraphQL serves one endpoint backed by a typed schema, and each client asks for exactly the fields it wants; gRPC defines a service as methods in a .proto file and, by default, sends Protocol Buffers over HTTP/2. For a public API, REST is the common default, GraphQL suits clients that need flexible queries across related data, and gRPC suits calls between your own internal services.
Key takeaways
- REST is the most used style in Postman's 2025 State of the API survey: 93% of respondents use it, against 33% for GraphQL.
- GraphQL cuts the number of round trips by letting one query return related objects with only the fields asked for.
- gRPC trades readability for compact binary messages and generated client code, which fits internal service-to-service calls.
- Speed depends on payload size, network and call count more than on the style alone; there's no universal ranking.
- Behind a unified API, a vendor's API style stops being your problem: Unified.to presents REST, GraphQL and other vendor APIs through one REST API per category.
How do REST, GraphQL and gRPC compare?
REST, GraphQL and gRPC differ in how a client addresses the API, what format the data travels in, and what contract describes the API.
| Dimension | REST | GraphQL | gRPC |
|---|---|---|---|
| How a client calls it | HTTP methods (GET, POST, PUT, DELETE) on resource URLs | A query or mutation sent to one endpoint | A method call on a generated client stub |
| Data format | Usually JSON | JSON responses | Protocol Buffers by default |
| Contract | Optional; often an OpenAPI document | A GraphQL schema, required | A .proto file, required |
| Transport | HTTP | Usually HTTP | HTTP/2 |
| Browser clients | Native | Native | Through gRPC-Web |
| Fetching related data | One request per resource, unless the API offers expansion or embedding | One query can request related objects and only the fields needed | Whatever the method's response message defines |
| Typical use | Public APIs and most web back ends | Front ends and clients that need flexible queries | Internal service-to-service calls |
What is REST?
REST (Representational State Transfer) is the architectural style Roy Fielding defined in his doctoral dissertation, which "introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems". Its interface constraints include "identification of resources" and "hypermedia as the engine of application state".
In practice, an API called RESTful usually means resources at URLs, HTTP methods for reading and writing them, and JSON bodies. Many don't follow every constraint, so two REST APIs can differ a lot in paths, pagination and error formats. An OpenAPI document describes a REST API's endpoints and shapes in a machine-readable form, which is what SDK generators and other developer software read.
REST is the most common style: in Postman's 2025 State of the API report, "REST still dominates at 93%" across more than 5,700 respondents. The survey reflects Postman's own audience of API developers, so read it as usage among that group.
What is GraphQL?
GraphQL is an API style in which a client queries a typed schema for exactly the data it needs; graphql.org describes it as enabling "flexible, versionless APIs powered by a strong type system".
Where a REST client might call /user, then /todos, then /news, a GraphQL client sends one query naming the objects and fields it wants. That cuts round trips for front ends that assemble a page from several kinds of data. The trade-offs are on the server: one flexible endpoint can make caching and rate limiting harder than with fixed REST URLs.
Postman's 2025 survey puts GraphQL use at 33%. Some large APIs have moved to it: Shopify says "The REST Admin API is a legacy API as of October 1, 2024" and "Starting April 1, 2025, all new public apps must be built exclusively with the GraphQL Admin API" (Shopify).
What is gRPC?
gRPC is a remote procedure call framework in which "a client application can directly call a method on a server application" on another machine, as if it were a local function (grpc.io). "By default, gRPC uses Protocol Buffers" for both the interface definition and the messages.
Protocol Buffers is, in Google's words, "like JSON, except it's smaller and faster, and it generates native language bindings". gRPC "largely follows HTTP semantics over HTTP/2", with support for full-duplex streaming, and browser clients reach it through gRPC-Web, which the gRPC FAQ lists as "Generally Available".
Generated stubs and a strict .proto contract suit teams that own both the client and the server. Binary messages are harder to read in logs and less familiar to outside developers, one reason public APIs more often use REST.
Which is fastest?
No style is fastest in every case: gRPC's binary messages are smaller than the same data in JSON, GraphQL can replace several REST calls with one, and REST can be cached at the URL level, so the result depends on payload size, network and how many calls a task takes.
Measure with your own payloads. A REST API that offers field selection or embeds related objects closes much of the round-trip gap, and a GraphQL query that asks for too much returns a large JSON response.
Which should you use?
Choose by who calls the API and what they need from it.
| If you're building | Use |
|---|---|
| A public API for outside developers | REST, described with OpenAPI |
| An API for your own front ends that assemble data from many related objects | GraphQL |
| Calls between your own internal services, with streaming or strict contracts | gRPC |
Which style does Unified.to use?
Unified.to is a REST API: one API per category, with paths such as /hris/{connection_id}/earning, published as an OpenAPI document and wrapped in official SDKs for TypeScript, Python, PHP, Java, Go, C# and Ruby.
The vendors behind it use whatever style they chose. Several of the integrations in Unified.to's docs sit on GraphQL APIs: monday.com and Linear are GraphQL-only, and Shopify requires new public apps to use its GraphQL Admin API (OAuth app guides in the docs, read 19 October 2026). Your code calls the same REST model either way, and Unified.to handles each vendor's authorization, pagination and field names. For an endpoint outside the model, the Passthrough API calls the vendor's own API on the same connection. AI agents reach the same connections through Unified MCP. For what a unified API does, see What Is a Unified API?.
→ Start your 30-day free trial
Written by Mallory Greene.
About the author: Mallory Greene is Head of Marketing at Unified.to_. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto._