Challenge 1: Choose a Versioning Strategy — Possible Solution
====================================================================

(a) Public API, thousands of external consumers who don't read docs closely
    -> RECOMMEND: URL versioning (/v1/users, /v2/users).
    Justification: with thousands of consumers you don't control and
    can't assume will read a changelog, the version needs to be
    impossible to miss. A version baked into the URL itself shows up
    in every request they write, every piece of documentation they
    read, and every support ticket they file — there's no way to
    "forget" it's there. Header versioning is easy for a large,
    loosely-coordinated audience to overlook entirely, since it's
    invisible unless someone deliberately goes looking for it.

(b) Internal API, one team, reviewing every deploy together
    -> RECOMMEND: header versioning (or even no versioning at all,
       with a "just update the one internal consumer" policy).
    Justification: when the entire audience is one team that already
    coordinates deploys together, the main downside of header
    versioning (poor visibility to a broad, uncoordinated audience)
    simply doesn't apply — everyone already knows what's changing
    because they're the ones changing it. This lets the API keep
    "purer" REST URLs. In many real internal-API situations, teams
    skip formal versioning altogether and just coordinate breaking
    changes directly, since there's no external audience to protect.

WHY THIS WORKS AS AN ANSWER
------------------------------
The right versioning strategy isn't a fixed best practice — it's a
tradeoff between visibility and purity, and the correct side of that
tradeoff depends entirely on how much control and coordination you
have over your consumers. A public API with no relationship to its
callers needs maximum visibility; an internal API with full
coordination can afford to prioritize architectural cleanliness
instead.