gRPC vs REST

API design: REST, HTTP, GraphQL and gRPC Mid-level Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

You deleted field 4 (discount) from a protobuf message. What else must you do?

Options
Hint 1 of 1

What would an old client think a new field 4 is?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Mark 4 (and the name) as reserved so it's never reused

Correct. Reusing the number would make old data decode as the wrong field.

Protobuf identifies fields on the wire by number, not by name. Reserving a deleted number and name stops someone reusing it later for a different field that old readers would decode wrongly.

Why not the others?
  • B Renumber the remaining fields to close the gap. Renumbering breaks every existing client.
  • C Nothing; protobuf ignores missing fields. True for reading, but a future field 4 would be misread by old clients.
  • D Bump the package version. Doesn't stop field-number reuse.

30-second answer

gRPC uses Protocol Buffers over HTTP/2: compact binary messages, generated typed clients in many languages, deadlines and cancellation built in, and streaming in either direction. It suits internal service-to-service calls where both sides are yours and latency matters. JSON over HTTP is easier to debug with curl, works in every browser and through every proxy, and is the better default for public APIs.

Practise saying it · 30 s. No recording, just a timer

gRPC or REST?

Say your answer out loud, then check which of these points you covered:

  • Protobuf over HTTP/2
  • Typed clients, deadlines, streaming
  • Internal vs public
  • Field-number rules
  • L7 balancing

Deep dive

Browsers need gRPC-Web or a translating proxy.

Protobuf evolution rules: never reuse a field number; add fields as new numbers; removed fields get reserved.

HTTP/2 multiplexing means long-lived connections; L4 load balancers can pin all traffic to one backend, so use L7 or client-side balancing.

gRPC status codes (DEADLINE_EXCEEDED, UNAVAILABLE…) differ from HTTP codes.

Common mistakes

  • Reusing a protobuf field number after deleting a field.
  • Using L4 load balancing for gRPC and seeing one hot backend.
  • Exposing gRPC directly to third parties who expect REST.

Senior take & follow-ups

Compare on payload, typing, streaming, tooling and browser support, then pick per audience.

Follow-up questions

Think of your answer first, then open the hint.

  1. Why does gRPC load-balance badly behind L4?

    Show hint

    One long-lived HTTP/2 connection carries all requests.

  2. How do you add a field safely?

    Show hint

    New field number; old clients ignore it.

Related questions

Suggest a fix if something here is wrong or out of date.