This question tests whether you can evaluate APIs on the wire, not on vibes. The interviewer wants the actual mechanics — protocol, serialization, caching behavior, client compatibility — and a decision rule for when each one wins.
The mental model: three different contracts between client and server, with different costs per byte, different caching properties, and different failure modes.
REST — HTTP verbs over URLs with JSON bodies. Its strengths are boring and real: it rides on HTTP, so you inherit caching (ETags, conditional GETs), idempotency semantics for free (GET/PUT/DELETE), and load balancers and CDNs that understand it — and browsers can consume it directly. The costs: JSON is verbose, the contract is documentation rather than a schema, and clients over-fetch or under-fetch because the server decides what a response contains.
gRPC — HTTP/2 multiplexed streams with protobuf binary serialization. The contract is the .proto file, which generates client and server code, so contract mismatches become compile errors instead of runtime surprises. The wire format is compact — a payload that's 300 bytes of JSON can be 60 bytes of protobuf — and HTTP/2 multiplexing removes connection-level head-of-line blocking, so many small calls share one connection. The costs: browsers can't speak it natively (gRPC-Web is a proxy workaround), HTTP caching and intermediaries largely don't apply, and observability and load balancing require deliberate infrastructure. That's exactly why it dominates internal traffic.
GraphQL — one endpoint, a query language, and a response shaped to the query. The win is client-driven payloads: a mobile client asks for only the fields it renders, one round trip instead of N. The costs are real: the server executes arbitrary graph traversals, so the N+1 query problem moves from the client into your resolvers; caching gets harder because POST-based queries don't fit HTTP caches; and a deeply nested query is a DoS unless you enforce depth and complexity limits.
Tradeoffs and edge cases: the pattern that shows real experience: public external APIs → REST; internal service-to-service → gRPC; client-facing BFF for heterogeneous mobile devices → GraphQL. The trap the interviewer sets is "which is fastest?" — the honest answer is "fastest at what," because the bottleneck is usually round trips, payload size, and serialization, not the protocol label.