REST, GraphQL, gRPC and hypermedia
Prerequisites: 01-ecosystem
How does GraphQL avoid repeated owner loads?
Goal & mental model verified
API styles expose different contracts. REST centers resources and HTTP semantics; GraphQL executes a schema-selected field graph; gRPC defines RPC services/messages. Spring HATEOAS helps express links and affordances in representations.
[S46] [S47]Worked example · design exercise synthesis
A broker dashboard asks GraphQL for policies and owners. Request-scoped DataLoader batching can collect owner IDs, reducing repeated lookups without turning the API into one unrestricted database query.
[S46] [S47] [S62]Engineering decision synthesis
Choose REST for familiar interoperable resource APIs, GraphQL for client-shaped graphs, and gRPC for typed RPC requirements. Consider client support, evolution, authorization and observability alongside payload size.
[S46] [S47] [S62]Pitfall & diagnosis synthesis
GraphQL can hide N+1 fetching and expensive query shapes. Changing transport does not supply per-field/resource permissions. Hypermedia links should reflect permitted actions rather than grant authority themselves.
[S46] [S47] [S62]Improve & validate synthesis
Measure query cost and downstream calls. Enforce workload limits and compatible contract evolution; keep authentication, authorization and deadline behavior explicit for each transport.
[S46] [S47] [S62]Check yourself: Does DataLoader guarantee one query for the entire request?
No. It batches compatible loads; actual queries depend on keys, resolvers and backing implementation.