Challenge 3: Design a Multi-Style System — Possible Solution
====================================================================

(a) Public product-browsing API
    -> REST (or GraphQL if the product screens genuinely need
       varying, deeply nested data combinations per screen — but
       plain REST is a perfectly reasonable default for straightforward
       product browsing/searching).
    Applying Q1/Q3: broad external audience, and unless there's a
    stated need for wildly different data shapes across many
    different client screens, REST's simplicity wins here the same
    way it did in Challenge 1's weather API.

(b) Live order-tracking updates for a customer watching their delivery
    -> WebSockets.
    Applying Q2: this is explicitly continuous, real-time, two-way-
    feeling communication — the customer is watching a live-updating
    view, not making a single request and getting one answer. This is
    exactly the "genuinely two-way and continuous" case the chapter
    pointed toward the already-covered WebSockets course for.

(c) Letting partner logistics companies know the instant stock runs low
    -> Webhooks.
    Applying Q2: the partners aren't maintaining an open, continuous
    connection waiting for this one specific event — they just need
    to be TOLD the moment it happens, without polling constantly.
    That's precisely the "notify me later, don't make me keep asking"
    case the chapter assigned to Webhooks.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the same lesson as the chapter's own worked example, applied
to a new scenario: none of these three needs should be forced onto a
single API style. (a) is ordinary request/response, (b) is genuinely
continuous and bidirectional, and (c) is a one-off event notification
— three different SHAPES of communication problem, and the right
answer is three different tools, not one style stretched to cover
needs it wasn't built for.