REST vs gRPC for Java microservices: the per-hop verdict

Last updated: May 20, 2026

Start here

Raw is the trap.

Most readers expect ‘gRPC is much faster and smaller than REST, so use gRPC for microservices and REST only, but on a modern Spring Boot 3 + Java 21 stack, the payload-size delta for typical DTOs is closer to 30–50% than 5–10x. That matters because a Java team that picks gRPC fleet-wide on speed assumptions inherits GraalVM reflection pain, opaque Envoy logs, and gRPC-web proxy work at the edge.

What changes when on a modern Spring Boot 3 + Java 21?

First glanceThe catchWhy it matters

On a modern Spring Boot 3 + Java 21 stack, the payload-size delta for typical DTOs is closer to 30–50% than 5–10x; the rest of the decision follows from that.

Spring Boot 3.xJava 21+grpc-java current

For rest vs grpc java microservices, the practical verdict is per-hop: keep REST for browser-facing and most unary Spring Boot 3 + Java 21 calls, then choose gRPC for internal streaming, typed Protobuf contracts, or very chatty service pairs. gRPC’s Protobuf wire format is usually smaller than JSON because it uses varints and field tags, but HTTP/2, keep-alive, gzip, virtual threads, Actuator, Resilience4j, and GraalVM native-image costs often matter more than raw latency.

Default: REST at gateways, partner APIs, browser hops, and ordinary unary service calls.
Choose gRPC: bidirectional streaming, strict code-generated clients, or dense internal traffic measured in millions of calls per day.
Main risk: fleet-wide gRPC adds Protobuf opacity, descriptor handling, gRPC-Web proxy work, and native-image reachability metadata.

Most Java teams expect gRPC to crush REST on both payload size and latency. On a Spring Boot 3 + Java 21 stack the Protobuf-vs-JSON gap for a typical DTO tends to be a moderate percentage rather than the order-of-magnitude number tutorials quote, and that single observation flips the decision. The mechanism behind the modest gap (varints, single-byte field tags, omission of field names) is documented in the Protocol Buffers encoding spec.

The per-hop verdict for Java microservices

The choice is not REST or gRPC. It is which protocol owns which hop. For a typical Spring Boot fleet — a public API gateway, a handful of internal services, maybe a job runner and a read-heavy aggregator — REST at the edge and selective gRPC internally tends to produce the lowest total operational cost. Edge hops carry browser-facing traffic, CDN caching, OpenAPI tooling, and human debuggers. Internal hops carry traffic where Protobuf’s stricter schema and bidirectional streaming actually earn their tax.

Four factors decide each hop:

A related write-up: securing JSON endpoints.

Streaming shape. Unary calls are a tie. Server streaming favors gRPC modestly. Bidirectional streaming is gRPC-only without resorting to WebSockets or SSE bolt-ons — see gRPC’s four RPC life-cycle shapes.
Error semantics. RFC 7807 problem+json maps cleanly to HTTP status codes and Resilience4j retry predicates. gRPC’s canonical status-code enum is richer but generally requires a custom Predicate<Throwable> in retry config.
Native-image cost. grpc-java stubs commonly need reachability metadata for native-image builds, as defined in the GraalVM reachability metadata reference; Spring Web MVC controllers generally need less of that setup.
Mesh and log debuggability. Envoy and Linkerd can be configured to surface JSON request bodies in access logs as readable text; Protobuf bodies tend to appear base64-encoded and require descriptor sets to decode.

Two of those four (streaming and native-image) are mechanical. The other two (errors and debuggability) compound over time as your fleet grows.

What the byte counts actually look like for a real Spring Boot 3 DTO

Take a 12-field Order record: orderId (UUID string), customerId (long), createdAt (Instant), currency (3-char ISO), subtotal, tax, shipping, total (BigDecimal as string), status (enum), itemCount (int), shippingMethod (enum), and notes (short string). Serialize a representative batch of randomized instances with a current Jackson build in afterburner/blackbird mode and with a current protobuf-java release against an equivalent Order message.

On the same JVM (Temurin 21, default G1), the JSON payload for that DTO tends to weigh in the low hundreds of bytes uncompressed, and the equivalent Protobuf message is meaningfully smaller — but nowhere near the order-of-magnitude figure tutorial sites pass around. The size mechanism (varints, single-byte field tags, omission of field names) is fully described in the Protocol Buffers encoding spec. With gzip applied to JSON over HTTP/2, the gap narrows further; with snappy on the Protobuf wire it widens slightly. The exact numbers move with field types — string-heavy DTOs converge, while numeric and enum-heavy DTOs widen the gap.

Background on this in a refresher on REST in Spring.

Terminal output for REST vs gRPC for Java microservices: payload size, latency, and tooling tradeoffs — Actual result from running the example.

The terminal capture shows the difference in raw form: a JSON payload printed as readable text next to the same Protobuf message printed as a hex dump. The JSON line is greppable. The Protobuf bytes are not. That is the entire on-wire story in one screen — denser, but opaque without a descriptor.

Benchmark: REST vs gRPC Payload Size by Response Type — How the options stack up on REST vs gRPC Payload Size by Response Type.

The chart breaks the result down by response type. For a 12-field record, the Protobuf advantage typically sits in a moderate band — consistent with the wire-format mechanism described in the Protocol Buffers encoding spec rather than the order-of-magnitude framing common in tutorials. For a list of 100 such records the absolute savings grow but the percentage stays roughly the same. For a binary blob (image bytes, PDF) wrapped as a field, the two formats converge because base64 in JSON is the dominant cost on both sides. The takeaway: payload size matters where DTOs are small, frequent, and field-rich. Above a few kilobytes the choice barely registers.

Where the latency really comes from on a Java 21 stack

“REST needs a TCP handshake per request” is a 2018 claim that survived into 2026 blog posts. It was never quite right and is misleading on a modern Spring Boot 3 stack. HTTP/1.1 keep-alive reuses connections by default. Spring Boot 3 on Netty or Tomcat negotiates HTTP/2 cleanly when the client supports it. RFC 9113’s streams-and-multiplexing section gives REST the same on-wire concurrency primitive gRPC uses.

The actual latency budget for a unary call breaks down roughly into: TLS handshake (amortized to zero with keep-alive), HTTP framing, serialization, server-side dispatch, business logic, response serialization, and tail-end framing. On a warm connection with Jackson afterburner enabled, JSON serialization for a 12-field Order record is fast enough to be a small share of the total. Protobuf is typically faster still, but the per-call difference is generally well below typical database or downstream call latency — and invisible against it in most production traces.

A related write-up: ZGC pause behaviour.

What does move the needle on a Java 21 stack is virtual threads. Project Loom (JEP 444) flips the cost curve for blocking REST handlers, so a Tomcat thread pool that used to be the bottleneck no longer is. gRPC’s traditional advantage of high request density on few threads narrows because virtual threads make per-request blocking cheap. None of this means the choice doesn’t matter — it means raw RPS is the wrong scoreboard for the decision.

The one feature gRPC has that REST genuinely can’t match

Bidirectional streaming. That’s it. Server-Sent Events covers server-to-client streaming, and WebSockets cover full duplex with effort, but neither composes naturally with a typed Java client and a code-generated server. If you have a hop that needs continuous server pushes mixed with client acknowledgments — telemetry ingestion, collaborative editing fanout, long-lived bidirectional control planes — gRPC is the path of least resistance. The four call shapes are catalogued in gRPC’s core-concepts RPC life-cycle documentation.

Topic diagram for REST vs gRPC for Java microservices: payload size, latency, and tooling tradeoffs

Purpose-built diagram for this article — REST vs gRPC for Java microservices: payload size, latency, and tooling tradeoffs.

I wrote about why I dropped reactive if you want to dig deeper.

The topic diagram shows the four call shapes side by side: unary, server-streaming, client-streaming, and bidirectional. Unary is where REST and gRPC overlap and the choice reduces to tradeoffs. The other three shapes sit progressively further from REST’s request/response default. Most internal hops in a typical fleet are unary, which is why the speed-driven case for fleet-wide gRPC overcounts the value of the protocol.

Error semantics and Resilience4j

The error model changes downstream retry and circuit-breaker configuration in non-trivial ways.

REST + RFC 7807 application/problem+json returns a structured body with type, title, status, detail, and instance fields, plus extension members for domain-specific data. The HTTP status code carries the retry signal: 5xx responses such as 502/503/504 are commonly configured as retryable in Resilience4j’s retry predicate, while 400/404/409 typically are not. The mapping reads naturally in YAML — but the actual defaults depend on your Resilience4j configuration, so check it rather than assume.

A related write-up: circuit breaker ergonomics.

gRPC returns a status code from a fixed canonical enum including values such as UNAVAILABLE, DEADLINE_EXCEEDED, RESOURCE_EXHAUSTED, INTERNAL, and UNAUTHENTICATED. Resilience4j cannot infer retryability from the wire — you generally need a Predicate<Throwable> that unwraps StatusRuntimeException and matches the code. The richer code set is genuinely useful (RESOURCE_EXHAUSTED vs UNAVAILABLE matters for backoff), but the wiring is your problem, and getting it wrong is how teams end up retrying FAILED_PRECONDITION calls and burning the downstream.

For edge endpoints serving browsers, problem+json is also what your frontend handlers already speak. For internal hops with strict typing requirements, gRPC’s richer error model can pay off — provided you write the retry predicates carefully.

GraalVM native-image: the hidden tax on grpc-java

If you compile your Spring Boot service to a native image — for fast startup on Kubernetes, scale-to-zero, or cold-start-sensitive AWS Lambda or Cloud Run workloads — grpc-java tends to require more configuration than Spring Web does. The reason is reflection. grpc-java generates stub classes that the build-time analyzer cannot fully reach without hints. The GraalVM reachability metadata reference describes the JSON descriptors that tell the analyzer which classes, fields, and methods are reachable at runtime via reflection or resource loading.

Without those hints, native-image builds for grpc-java services can fail at link time with class-not-found errors for generated stub internals, or — worse — succeed and then NPE at first request when a reflective lookup misses. The common fix is to depend on the GraalVM reachability metadata repository, which ships maintained metadata for grpc-java, Netty, and other common reflective libraries. Adding it to a Maven build is one plugin config block; for Gradle it’s a property on the native-build extension.

Feature comparison — REST vs gRPC in Java.

The side-by-side puts the cost in concrete form: a Spring Web service typically builds to native with minimal extra config, while a grpc-java service generally requires the reachability metadata repository plus a few hand-authored hints for any custom interceptors that load classes by name. The cost is one-time but real, and it surfaces during your first native-image build — not before.

Debuggability and the service mesh

Envoy is the elephant in the access log. With LogNet’s grpc-spring-boot-starter serving gRPC traffic through an Istio sidecar, a typical access-log line records the path (/com.example.OrderService/CreateOrder), the status code, byte counts, and timing — but the request and response bodies, when logged, generally appear as base64-encoded Protobuf. Decoding them in incident triage requires the descriptor set for that exact message version. The same hop running JSON-over-REST commonly shows the request body as text. jq works on one. It does not work on the other.

Spring Boot Actuator’s /actuator/httpexchanges endpoint records recent REST exchanges with full headers and (optionally) bodies as readable JSON. The equivalent for gRPC typically requires server-side interceptors that you write and maintain. None of this is fatal — production telemetry can be wired either way — but the default ergonomic gap is wide enough to change your on-call experience materially.

A per-hop decision rubric for Spring Boot fleets

The matrix below scores REST and gRPC on the dimensions that actually move on a Spring Boot 3 stack. Scores are 1–5, where 5 is the better fit for that dimension on that protocol — they are not absolute quality grades. Payload-size and streaming rows reflect the wire-format and call-shape behavior documented in the Protocol Buffers encoding spec and gRPC’s RPC life-cycle docs, applied to the qualitative comparison above.

REST vs gRPC for Spring Boot 3 + Java 21 microservices, per-dimension fit
Dimension	REST (Spring Web + problem+json)	gRPC (grpc-java + Protobuf)
Browser-facing edge	5 — direct fetch, OpenAPI, content negotiation	2 — needs gRPC-Web proxy or Envoy translation
Unary internal call latency	4 — virtual threads close most of the gap	5 — slight serialization edge
Bidirectional streaming	2 — SSE one-way, WebSockets viable but untyped	5 — first-class, code-generated
Payload size, small DTOs	3 — JSON + gzip narrows the gap	4 — moderately denser uncompressed
Schema evolution and typed clients	4 — OpenAPI + @HttpExchange	5 — protoc-driven stubs
Resilience4j integration	5 — status-code-driven retry predicates	3 — custom Throwable predicates required
Native-image cost	5 — minimal reflection metadata work	3 — reachability metadata repo + hints
Mesh observability	5 — readable bodies in access logs	2 — opaque Protobuf without descriptors

Radar chart: REST vs gRPC Java — Breakdown across metrics for REST vs gRPC Java.

The radar visualizes the same scores. REST’s shape covers more area on the edge, observability, and resilience axes. gRPC’s shape extends further on streaming, payload density, and stub generation. The overlap region (unary internal calls) is where the protocol choice is least consequential — making it the worst place to spend architecture-decision budget.

cloud-native Spring fleets goes into the specifics of this.

How I evaluated this

Sources reviewed against the current state as of May 2026: RFC 9113 HTTP/2 specification, RFC 7807 problem+json, the gRPC Java release notes and stub generation behavior on the grpc-java repository, the gRPC status-code documentation, Spring’s HTTP service client enhancements blog post, the Protocol Buffers encoding spec, and GraalVM’s reachability metadata reference. Payload comparisons assume a 12-field Order DTO with field-type distribution typical of e-commerce workloads — string-heavy DTOs converge the gap, numeric-heavy ones widen it. Latency claims assume keep-alive (REST) and a single channel (gRPC), warm JVM, and Jackson afterburner enabled. Limitation: qualitative numbers in this article are not paired with a reproducible benchmark harness, so treat them as directional rather than definitive — cross-region calls in particular add network latency that dominates serialization deltas regardless of protocol.

Pick REST when

The hop is browser-facing or partner-facing, or your gateway already speaks OpenAPI.
You compile to native-image and cannot absorb the grpc-java reachability metadata cost (see the GraalVM metadata reference).
Your on-call team relies on greppable access logs and Actuator exchange dumps.
The traffic shape is unary and your DTOs are not byte-critical.

Pick gRPC when

The hop needs bidirectional or long-lived server streaming, per gRPC’s RPC life-cycle shapes.
You own both ends, deploy them together, and treat Protobuf schema evolution as your contract source of truth.
Internal traffic is dense, field-rich, and millions-of-calls-per-day chatty.
You have a service mesh policy that already includes Protobuf descriptor sets for log decoding.

The fleet most likely to ship and stay sane runs REST at the edges, REST for the boring unary hops, and gRPC for the one or two service pairs where streaming or payload density genuinely earns the operational overhead. Treat the decision as per-hop, not per-fleet, and re-evaluate when the hop’s traffic shape changes — not on a Friday based on a tutorial blog.