REST & gRPC — Theory

REST & gRPC — Theory (interview deep-dive)

Why gRPC is faster than REST/JSON

1. Binary protobuf vs text JSON — typically 3-10× smaller payload.
2. HTTP/2 — multiplexed streams, header compression. REST commonly still HTTP/1.1 in practice.
3. No reflection at runtime — generated code is direct.
4. Streaming first-class — no WebSocket tunneling.
5. Deadlines & cancellation built into the protocol.

In practice gRPC is reported ~5-10× faster on small messages, less so on large.

When REST still wins

• Browsers — gRPC over HTTP/2 doesn’t expose all features to JS. Need gRPC-Web with proxy translator.
• Public APIs — consumers expect curl, Postman, OpenAPI.
• CDN / edge caching — REST GETs are HTTP-cacheable; gRPC isn’t.
• Tooling familiarity — gRPC needs codegen/build setup; REST is “just HTTP”.

Idempotency in REST

• GET, PUT, DELETE are idempotent by spec. POST is not — needs explicit Idempotency-Key header for safe retries.
• Server stores response keyed by (client_id, key) for a window. Returning cached response on repeat.
• Important for payment / order creation APIs.

Idempotency in gRPC

• gRPC marks methods as idempotent in service options (option idempotency_level = IDEMPOTENT).
• Client may retry idempotent calls automatically (configurable via service config).
• Otherwise, never retried automatically — caller’s responsibility.

REST anti-patterns

• Verbs in URLs: /getUsers, /createOrder. Use GET /users, POST /orders.
• Always returning 200 with status field in body. Use HTTP status codes properly.
• Mass assignment without filtering — accepting any field client sends.
• Versioning by adding new fields silently — breaking clients.
• Returning everything in one big response — no pagination.
• Error responses without machine-readable shape (use Problem Details RFC 7807).

Protobuf evolution rules

Safe:

• Add new fields with new numbers.
• Add new enum values (older clients see UNKNOWN if not handled).
• Add new methods.
• Add new messages.

Breaking:

• Reuse / renumber field tags.
• Change field type (mostly).
• Remove required field (proto2). proto3 fields are all optional under the hood.
• Rename a field (it’s serialized by number, but code uses name).

Use a schema registry (Buf Schema Registry, Confluent SR) to enforce backwards compat.

HTTP/2 deep concepts

• Frame: smallest unit. Stream contains an ordered sequence of frames.
• Stream: bidirectional flow within a single connection. Has its own state machine.
• HPACK: header compression with shared dictionary across streams.
• Flow control: per-stream and per-connection windows. Receiver advertises capacity.
• Settings: tunable params (max concurrent streams, initial window).
• Server push is deprecated/disabled in browsers — don’t rely on it.

HTTP/3 / QUIC (for context)

• Built on UDP. Removes TCP head-of-line blocking entirely (per-stream losses isolated).
• Faster connection setup (0-RTT possible).
• Many CDNs support; backend gRPC adoption emerging.

Common interview Qs

1. PUT vs POST? PUT is idempotent and addresses a specific resource (you know the id). POST creates with server-chosen id or invokes an action.
2. PATCH semantics? Apply partial change. Uses JSON Patch (RFC 6902) or JSON Merge Patch (RFC 7396) — but most APIs use ad-hoc merge.
3. Why might gRPC fail behind a corporate proxy? HTTP/2 over h2c (cleartext) blocked, or proxy doesn’t preserve trailers. Use TLS, dedicated L7 proxy (Envoy).
4. gRPC error codes vs HTTP status? Distinct enums. Some libs map: NOT_FOUND → 404, UNAVAILABLE → 503.
5. What goes in headers vs body? Headers: metadata (auth, content-type, idempotency key, request id). Body: domain payload.
6. Why is 429 Too Many Requests correct here? Rate-limited; include Retry-After.
7. gRPC streaming use case? Server-streaming for live updates, bidi for chat / collaborative editing, client-streaming for upload-many-process-once.
8. Pagination at scale? Cursor-based (keyset). Avoid OFFSET on large datasets.
9. CORS — what do servers send? Access-Control-Allow-Origin, Allow-Methods, Allow-Headers. Preflight via OPTIONS. Don’t echo * if Authorization is needed.
10. What’s gRPC-Web? Limited subset over HTTP/1.1 + HTTP/2 with a proxy (Envoy) translating to native gRPC for the backend.

Performance tuning

REST/JSON

• Use gzip or br compression.
• Persistent connections (keep-alive).
• HTTP/2 if available.
• Pre-compress static assets.
• ETag/304 for cacheable GETs.

gRPC

• Connection pooling — single connection multiplexes many calls; sometimes pool size 1 is fine.
• Tune flow control window for large streaming.
• Compression (gzip) at transport level.
• Avoid polling — use server streaming.
• Set sensible deadlines on every call.

Schema-first vs code-first

• Schema-first (proto, OpenAPI): contract is artifact. Multiple languages generated. Easier to evolve.
• Code-first (decorate code, generate spec): faster start. Risk: spec drifts, single-lang.

For multi-team / multi-language, schema-first wins.