Challenge 1: Classify HTTP Methods — Possible Solution
====================================================================

(a) Fetch a user's profile
    -> GET. Pure retrieval, no side effects, safe to call repeatedly.

(b) Create a new order
    -> POST. Creating something new is the classic POST case — each
       call is expected to create a NEW order, which is exactly why
       POST is not idempotent (calling it twice makes two orders,
       not one).

(c) Update just the email field of an existing user
    -> PATCH. Only one field is changing, not the whole record —
       this is a PARTIAL update, which is what PATCH means.

(d) Delete a comment
    -> DELETE. Removing an existing resource.

(e) Replace an entire user record with new data
    -> PUT. The whole resource is being REPLACED with what's sent —
       this is the full-replacement case PUT is meant for, as
       opposed to (c)'s partial update.

WHY THIS WORKS AS AN ANSWER
------------------------------
The (c) vs (e) pair is the one worth double-checking: both are
"updating a user," but they're different in an important way — (c)
touches one field and should be PATCH, while (e) replaces the entire
record and should be PUT. This is exactly the PUT/PATCH distinction
this chapter's gotcha box warned about: using the wrong one doesn't
just violate a naming convention, it changes what happens to fields
that AREN'T included in the request body.