REST vs RPC

Two Mental Models

 REST: everything is a RESOURCE with representations;
       verbs come from HTTP; state transfers via payloads
 
 RPC : everything is an ACTION (procedure call);
       methods are named operations: CancelTrip(trip_id)
       transport is incidental (HTTP, TCP, whatever)
 
 same system, both styles:
 REST  POST /trips/123/cancellations   {reason}
 RPC   TripService/CancelTrip          {trip_id, reason}

The Actual Trade-offs

Dimension	REST	RPC (gRPC-style)
Model fit	CRUD-ish domains	Action-heavy domains
Contract	Convention + OpenAPI	Strict .proto schema
Wire efficiency	JSON text	Binary protobuf (~5–10x smaller)
Streaming	Limited (SSE/chunks)	First-class bidirectional streams
Browser support	Native	Needs gRPC-Web/transcoding layer
Cacheability	HTTP caching free	None — app-level only
Learning curve	Lower for public devs	Codegen does heavy lifting
Evolution discipline	Your responsibility	Proto rules enforce it

When Each Wins

 choose REST-flavored HTTP when:
 - PUBLIC developers consume it (ubiquity, curl-debuggability)
 - CDN/HTTP-cache value is high (read-heavy public data)
 - resources model naturally (catalogs, accounts, documents)

 choose gRPC/RPC when:
 - INTERNAL service-to-service traffic (both sides codegen'd)
 - latency/throughput budgets are tight (binary + multiplexed HTTP/2)
 - streaming matters (live updates, telemetry)
 - strict contracts prevent cross-team drift

The industry equilibrium reflects exactly this split: public edges speak REST/JSON, internal meshes increasingly speak gRPC.

Hybrid Reality

 Mobile App ──► [ API Gateway ] ──► internal gRPC mesh
              REST/JSON outside     protobuf inside
 
 gateway transcodes: one contract surface for clients,
 efficient transport between services — not either/or,
 a deliberate layering decision

GraphQL’s Position

GraphQL sits orthogonally: it’s about query shape (client-specified projections), usually over a single POST endpoint. It solves over/under-fetching, not transport. Compare it to REST when clients need flexible reads; compare nothing to it when you need HTTP caching — it largely forfeits that.

Interview Framing

Protocol-choice beats appear in nearly every design interview. Scored pattern: pick by consumer and traffic type (“public mobile → REST at edge; service-to-service → gRPC”), name two concrete reasons from the table (streaming, cacheability), and mention gateway transcoding as the reconciliation. Reciting “REST vs gRPC” without naming who consumes it misses the actual decision variable.