Challenge 3: Pick the Right Style — Possible Solution
====================================================================

(a) A public API for third-party developers to integrate with — REST.
Third-party developers need something they can explore, debug, and
integrate with using widely available, universal tooling — curl, a
browser, Postman (per the API Testing & Tooling course) — none of
which work naturally against gRPC without extra proxying (this
chapter's browser-support gotcha). REST's broad compatibility and
human-readable JSON make it the right default for an audience you
don't control the tooling of.

(b) High-frequency internal calls between an order service and an
inventory service — gRPC. This is exactly gRPC's original design
target: service-to-service traffic where BOTH ends are code the same
organization controls, and where HTTP/2 multiplexing plus compact
binary Protobuf payloads genuinely matter at high call volume. There's
no third-party developer experience to protect here, so gRPC's tooling
requirements are a non-issue.

(c) A mobile app that needs to fetch a customizable set of fields per
screen — GraphQL. This is GraphQL's defining strength: a client
specifying exactly which fields it needs for a given screen, avoiding
both REST's common over-fetching (getting fields the screen doesn't
use) and under-fetching (needing multiple round trips for one screen).
Neither REST's fixed resource shapes nor gRPC's fixed RPC signatures
solve this per-screen flexibility problem as directly as GraphQL's
client-specified query shape does.