Challenge 3: Choose REST or GraphQL — Possible Solution
====================================================================

SCENARIO: A simple public webhook receiver with exactly one client and
no varying data-shape needs.

RECOMMENDATION: REST

JUSTIFICATION (using this chapter's "when REST still wins" section)
------------------------------------------------------------------------
- No varying data-shape needs: GraphQL's central value proposition is
  letting DIFFERENT clients request DIFFERENT shapes of the same
  underlying data. A webhook receiver has exactly one client (the
  service sending the webhook) sending exactly one fixed payload shape
  — there is no over-fetching or under-fetching problem here to solve
  in the first place, because there's no variation in what's being
  requested or returned to begin with.

- Simple, single-purpose endpoint: This chapter explicitly calls out
  "simple CRUD APIs with few clients" as a case where REST remains the
  better fit. A webhook receiver is about as simple and single-purpose
  as an API endpoint gets — one URL, one expected payload shape, one
  consumer. Introducing a GraphQL schema, resolvers, and a query
  language for this would add real complexity (a schema to define and
  maintain, a runtime to operate) without solving any actual problem
  that complexity is meant to address.

- Webhooks are explicitly listed as a REST-favoring case: The chapter
  specifically names "file uploads and simple webhooks" as scenarios
  where REST is still the right choice — this scenario is close to a
  textbook match for that guidance.

- No caching or flexible-querying benefit applies: GraphQL's other
  advantages (avoiding endpoint sprawl across many different client
  needs, single-round-trip nested fetching) don't apply either — there's
  no sprawl to avoid (a webhook receiver typically has one endpoint by
  nature) and no nested/related data being fetched by a client in the
  first place, since the flow here is the OTHER service pushing data IN,
  not a client querying data OUT.

WHY THIS WORKS AS A DECISION
-----------------------------
None of GraphQL's actual strengths (solving over/under-fetching for
multiple varied clients, replacing endpoint sprawl) apply to a scenario
with exactly one client and one fixed shape — there's no real problem
for GraphQL to solve here, only added operational complexity for no
benefit. This mirrors the exact judgment call from Chapter 4 of the
WebSockets course: match the tool to what the scenario actually needs,
not to which technology feels more current.