Challenge 3: SOAP or REST? — Possible Solution
====================================================================

(a) Bank-to-bank wire transfer system requiring guaranteed-exactly-once
    delivery and formal contracts
    -> RECOMMEND: SOAP.
    Justification: this scenario needs exactly the guarantees SOAP's
    WS-* standards were built for — WS-ReliableMessaging for
    guaranteed exactly-once delivery (critical: a wire transfer must
    never be silently duplicated or silently lost), WS-AtomicTransaction
    for multi-step transactional consistency across systems, and
    WS-Security for message-level security independent of the
    transport. REST has no standardized built-in equivalent for any
    of these — you'd have to build guaranteed-exactly-once delivery
    and formal contract enforcement yourself, reinventing what SOAP
    already provides as an established standard.

(b) Public weather API for mobile app developers
    -> RECOMMEND: REST.
    Justification: mobile developers building against a public API
    want something lightweight, easy to test with common tools, and
    quick to integrate — REST's plain HTTP + JSON approach is far
    easier to consume from a phone app than parsing SOAP's XML
    envelopes would be, and a weather API doesn't need SOAP's
    heavyweight transactional/security guarantees. There's no wire
    transfer here — worst case, a dropped weather request just gets
    retried.

WHY THIS WORKS AS AN ANSWER
------------------------------
The deciding factor in both cases isn't "which technology is newer"
or "which one is generally better" — it's whether the SPECIFIC
guarantees SOAP provides (formal contracts, exactly-once delivery,
transactional consistency, message-level security) are actually
needed for the problem at hand. A wire transfer genuinely needs those
guarantees; a weather lookup does not. Matching the tool to the
actual requirement, rather than a general preference, is exactly the
tradeoff this chapter's comparison table was meant to make visible.