REST vs GraphQL vs gRPC vs OData: What Each Is, What It Costs, and How to Choose

An API is the agreed way one program asks another program for data or for an action. REST, GraphQL, gRPC and OData are four popular ways to define that agreement, and they get compared in blog posts as if they were four brands of the same product. They are not. One is an architectural style, one is a query language, one is a remote-call framework, and one is a standard that fixes the details REST leaves open. Choosing well starts with seeing that difference.

This guide explains each one in plain terms, runs the same question through all four, and measures one thing I could measure honestly on a laptop: how many bytes the same data takes on the wire. It ends with a way to choose and the mistakes that cause the most pain. Where I did not test something, the text says so.

The short version

Every cell has caveats that the sections below fill in. Read the table as a map, and not as a scorecard.

One question, asked four ways

Suppose a screen needs the name of customer 42 and their three newest orders. Here is how each style expresses that.

REST puts each kind of thing at its own address, so the plain version is two requests:

GET /customers/42
GET /customers/42/orders?sort=-createdAt&limit=3

Many teams add a convenience option such as ?include=orders to save the second trip. That works, but nothing standardizes the option name, so every API invents its own.

GraphQL sends one request to one endpoint, and the request is a description of the data you want:

query {
  customer(id: 42) {
    name
    orders(first: 3, orderBy: CREATED_DESC) { id status totalCents }
  }
}

The reply has the same shape as the question, and only the fields you named.

gRPC has no URLs for data. You call a named method that the server author defined in a contract file:

service Shop {
  rpc GetCustomerWithOrders(GetCustomerRequest) returns (CustomerWithOrders);
}
message GetCustomerRequest { int64 customer_id = 1; int32 order_limit = 2; }

If another screen needs a different slice, the server team adds another method. The server decides the shape.

OData answers with URL conventions that the standard defines, so the client shapes the reply without a custom endpoint:

GET /odata/Customers(42)?$select=Name&$expand=Orders($select=Id,Status,TotalCents;$orderby=CreatedAt desc;$top=3)

The standard says options for an expanded related collection go in parentheses, separated by semicolons, and may include $filter, $select, $orderby, $skip, $top, $count, $search and $expand.⁸

Notice where the control sits. In REST and gRPC the server fixes what each call returns. In GraphQL and OData the client chooses, and the server has to survive whatever the client chooses. Most of the trade-offs below follow from that one fact.

REST: HTTP used as designed

Roy Fielding’s dissertation defines REST as a set of constraints: client and server are separate, each request carries everything needed to understand it (stateless), responses say whether they can be cached, components talk through a uniform interface, and layers like proxies can sit between them.¹ The uniform interface itself has four parts: resources have identifiers, you change them through representations, messages describe themselves, and hypermedia drives what the client does next.¹

In daily use, “a REST API” usually means resource URLs, HTTP verbs and JSON. Martin Fowler’s maturity model describes the steps: one endpoint tunneling calls (level 0), separate resources (level 1), correct use of HTTP verbs and status codes (level 2), and links in responses that tell the client what it can do next (level 3).⁹ An API with separate resources and correct verbs but no links sits at level 2 and is still commonly called REST. A strict reading of Fielding asks for level 3: Fowler reports that Fielding has said level 3 is a precondition of REST.⁹

What you get for free is HTTP’s own rules. A safe method is one whose meaning is essentially read-only, and an idempotent method is one where repeating the request has the same effect as sending it once. RFC 9110 puts GET in the safe group and PUT and DELETE (along with the safe methods) in the idempotent group.¹⁰ That is why a client or proxy can retry a failed GET or PUT without asking anyone.

It is also why REST caches so well. A response to a GET can be stored by browsers and CDNs (content delivery networks, servers that keep copies of responses close to users). A response to a POST is cacheable only when it carries explicit freshness information and a Content-Location header equal to the request URL.¹⁰ The next two styles lean on POST, and that is where they lose this free cache.

The costs are the ones in the table. Fixed response shapes mean a screen may download fields it never shows (over-fetching) or make several requests to assemble one view (under-fetching). There is no machine-readable contract unless you write one, and OpenAPI is the common choice for that.⁵

GraphQL: the client writes the query

The GraphQL specification defines a query language and exactly how a server executes a query against a typed schema, which is a list of the types and fields the server offers.² Over HTTP, the rules live in a separate draft specification: a server must accept POST, may accept GET, and a GET must never run a mutation, meaning an operation that changes data.¹¹

Errors are reported in the body, and that surprises people. The draft says that if a query executes and some fields fail, the server should still reply 200 OK, because the specification treats a result with partial data as a successful execution.¹¹ It recommends 4xx codes only for requests that cannot be processed at all, such as invalid JSON (400) or a query that fails validation (422).¹¹ It even proposes a custom code, 294 Partial Success, for responses that carry both data and errors, and says plainly that no official HTTP code fits.¹¹ The practical consequence: a dashboard that counts only non-2xx responses will miss most GraphQL failures. You have to look inside the errors array.

The N+1 problem. Say a query asks for 20 customers and each one’s orders. A naive server runs one database query for the customers and then one more per customer, 21 queries for one request. The DataLoader library exists for this. It collects the individual loads that happen in one tick of the event loop and sends them as a single batch.¹² Without something like it, GraphQL’s flexibility turns into database load.

Security needs deliberate limits. Because the client writes the query, the OWASP cheat sheet lists the risks: unlimited query depth and size can cause denial of service, one request can carry many batched operations that slip past per-request rate limits, introspection (the feature that lets anyone ask the server for its full schema) can expose private fields, and authorization has to be checked on every object, not just at the front door.¹³ Its recommendations are depth and amount limits, query cost analysis, timeouts, pagination, limits on batching, introspection turned off in production, and authorization checks on both edges and nodes.¹³

gRPC: calling functions on another machine

gRPC is a remote procedure call framework: the client calls what looks like a local function, and the framework sends it to a server. You describe the service in a .proto file, and tools can generate client and server code from it. Protocol Buffers are the default format for that description and for the data.³

It is HTTP/2 underneath. The protocol document describes gRPC carried over HTTP/2 framing. Every call is a POST to a path of the form /Service/Method, the content type is application/grpc, and each message is prefixed with a 1-byte compression flag and a 4-byte length.⁶ The result status travels in trailers, headers sent after the body, as a grpc-status value. The same document notes that a gRPC error response uses HTTP status 200, and that is why a server should answer 415 to any request whose content type is not gRPC: otherwise another HTTP/2 client could read an error as a success.⁶ Like GraphQL, gRPC reports failure in a place plain HTTP monitoring does not look.

Four call shapes. A call can be unary (one request, one response), server streaming, client streaming, or bidirectional streaming where both sides send message sequences independently.³ This is the biggest capability the other three do not have. Clients also set a deadline, and a call that runs past it ends with DEADLINE_EXCEEDED.³ The protocol carries it as a grpc-timeout header.⁶ Cancellation, by either side, ends the call immediately, and the documentation warns that changes made before cancellation are not rolled back.³

How protobuf stays small. Field names are not sent. The encoding uses the field’s number as the key, and the name and type are known only by whoever holds the .proto file.¹⁴ Each field is written as a tag, computed as (field_number << 3) | wire_type, followed by the value, and integers use varints, which take fewer bytes for smaller numbers.¹⁴ The guide’s example: setting field 1 to 150 takes three bytes, 08 96 01.¹⁴ Field numbers 1 through 15 fit in a one-byte tag.¹⁵ The rule that follows is strict: field numbers should never be reused, and a deleted field’s number must be reserved, because reuse makes decoding ambiguous.¹⁵

Browsers are the sore spot. Plain gRPC is not what web pages call. Web clients use gRPC-Web, which reaches the service through a special proxy, Envoy by default.¹⁶ The gRPC-Web README says unary and server-side streaming are supported, client-side and bidirectional streaming are not, and in the binary grpcweb mode only unary calls work.¹⁶ If your callers are browsers or third parties with ordinary HTTP tooling, that is a real cost. A bridge exists in the other direction too: grpc-gateway reads annotations in the .proto and generates a reverse proxy that offers the same service as a REST JSON API.¹⁷

OData: REST conventions, written down

OData stands for Open Data Protocol, and OData version 4.01 was approved as an OASIS Standard on 23 April 2020.¹⁸ It standardizes the things REST leaves to each team: headers, status codes, URL conventions, media types, payload format, batch requests and change tracking.⁴ If REST is “use HTTP sensibly,” OData is “use HTTP exactly like this.”

A service publishes a $metadata document describing its data model in machine-readable form, and responses point back to it with @odata.context.⁴ A collection reply puts the items in value and gives a @odata.nextLink for the next page. A created entity returns 201 Created with a Location header, and updates and deletes return 204 No Content.⁴

The appeal is that generic tools and clients can work against any OData service, and a new filter does not need a new endpoint. The cost is that you have handed clients a query language over your data. In ASP.NET Core OData, for example, the query options are converted into a LINQ expression and then into SQL by the data layer.¹⁹ Microsoft’s documentation shows how a service decides what to allow: you switch on Select, Filter, OrderBy, Expand and Count individually, set a maximum $top, and can restrict a single action to specific options with AllowedQueryOptions.¹⁹ I did not find OData-specific abuse guidance in the sources I read, but the reasoning behind OWASP’s GraphQL advice applies the same way to any API where the client can ask for nested, filtered data. Treat that as my inference, and set the limits.

Measured: how big is the same data on the wire?

Size is the number people quote most and understand least, so I measured it. The script builds 50 order records (an id, a customer id, a status, a total in cents, a timestamp and an item count) and encodes them each way. Protobuf is encoded by a small hand-written encoder that I checked against the documented 08 96 01 example, so the result needs no installed libraries. Sizes are bytes, once raw and once after gzip at level 6.²⁰

Four things stand out.

Most of the gap is field names and text numbers. One order is 19 bytes in protobuf and 103 bytes in JSON with epoch integers, because JSON repeats every field name for every record and writes numbers as digits. Writing the timestamp as an ISO date string instead of an integer costs another 600 bytes across the 50 records.

Compression closes most of it. Gzip works well on repeated text, so the 5.3 times raw advantage becomes 1.6 times (654 against 1,039 bytes). If your HTTP responses are already compressed, protobuf’s size advantage is smaller than the headline suggests. Whether gRPC compression is on in a given deployment is a configuration question, because the protocol carries a per-message flag.⁶

GraphQL and OData envelopes are cheap. The wrapper objects added 20 and 76 raw bytes to a 5,876-byte array, and still added 18 and 75 bytes after gzip. The envelope is not why you would avoid either one.

The request side differs more than the response. For the “customer 42 with 3 orders” question, the REST URL was 55 bytes, the OData URL 109, the GraphQL body 106, and the gRPC request 9 bytes of framed protobuf, before HTTP/2 headers.

What I did not measure: latency, CPU cost of parsing, behavior under load, or the effect of connection reuse. A smaller payload is not automatically a faster call, and these numbers come from one synthetic data set, not from your service.

How to choose

flowchart TD
  A["Who calls the API?"] --> B{"Mostly other services<br/>you run?"}
  B -->|"Yes, and you need streaming,<br/>strict contracts or small messages"| G["gRPC"]
  B -->|"No: browsers, partners,<br/>plain HTTP tools"| C{"Do clients need very<br/>different slices of connected data?"}
  C -->|"Yes, and you control<br/>the clients"| Q["GraphQL"]
  C -->|"No"| D{"Is it mostly CRUD and filtering<br/>over a data model, with generic tooling?"}
  D -->|"Yes"| O["OData"]
  D -->|"No"| R["REST"]

Combining is normal. A common arrangement is gRPC between internal services with REST or GraphQL at the edge facing clients, and grpc-gateway exists to serve a REST face from a gRPC service.¹⁷ The important part is to choose per boundary, not per company.

Mistakes that cost the most

• Treating HTTP 200 as success in GraphQL or gRPC. Both report errors somewhere else: the errors array in one, the grpc-status trailer in the other.⁶¹¹ Monitor those fields.
• Shipping GraphQL or OData with no limits. Depth, cost, page size and batching limits are part of the design, and OWASP’s list is a good checklist.¹³ An unlimited $top or $expand is the same class of mistake.
• Reusing a protobuf field number. It makes old and new messages decode into the wrong fields. Reserve deleted numbers.¹⁵
• Choosing gRPC for a browser-first product without budgeting for the proxy. gRPC-Web adds a component to run and removes client and bidirectional streaming.¹⁶
• Calling an API REST and then using POST for everything. That is level 0 in Fowler’s terms and gives up the caching and retry rules that HTTP offers.⁹¹⁰
• Picking by headline numbers. The size measurement above shows how the gap shrinks once compression is on. Measure your own payloads before using a speed or size argument to decide.

Where this guide can mislead

The four styles are bigger than one page. I did not cover versioning strategy, authentication, GraphQL subscriptions, GraphQL federation, OData’s $apply aggregation or batch endpoints, or gRPC load balancing. The GraphQL-over-HTTP specification I cite is a draft, and individual servers may behave differently, for example by returning other status codes for errors. The byte counts come from one synthetic sample of 50 small records. I read the specifications and vendor documentation but did not stand up a server in each style and test latency. If you spot something that is out of date, the sources below are where to check first.

References