Challenge 1: A Public Weather API — Possible Solution
====================================================================

RECOMMEND: REST.

APPLYING THE FRAMEWORK
------------------------------
Q1 (Who's the client?): A broad, external, uncoordinated developer
audience — points toward REST or GraphQL, not gRPC or SOAP.

Q2 (Request/response or something else?): A straightforward "give me
today's forecast for this location" — genuinely request/response, not
a live connection or an event notification.

Q3 (How complex are the client's data needs?): Simple and mostly
UNIFORM — nearly every consumer wants roughly the same shape of data
(temperature, conditions, maybe a forecast list) rather than wildly
different nested combinations per client. This is exactly the
"simple, fixed-shape access" case the chapter said REST handles well
WITHOUT needing GraphQL's extra flexibility.

Q4 (What guarantees are needed?): None of SOAP's formal
transactional/security guarantees are relevant here, and there's no
internal-performance requirement pushing toward gRPC.

WHY THIS WORKS AS AN ANSWER
------------------------------
The key insight this challenge is testing: GraphQL exists to solve
the problem of client data needs varying WIDELY across many different
consumers/screens. A weather API's requests are simple and largely
identical in shape regardless of who's calling it — there's no real
over/under-fetching problem to solve, so GraphQL's extra complexity
would be solving a problem that doesn't actually exist here. Choosing
the simplest style that fits, rather than the most sophisticated one
available, is itself the right call.