Challenge 2: WSDL vs No Contract — Possible Solution
====================================================================

WITH A WSDL-GENERATED SOAP CLIENT
------------------------------------
The WSDL contract already specifies the exact expected type for every
parameter (e.g. "this field must be an integer"). Client code is
GENERATED directly from that contract, typically in a strongly-typed
language like Java or C#. If a developer tries to pass a string where
the generated client code expects an integer, this fails at COMPILE
TIME (or immediately at code-generation/build time) — the mistake is
caught before the request is ever sent over the network at all, often
directly in the developer's editor or build pipeline.

WITH A PLAIN, UNDOCUMENTED REST CALL
------------------------------------
There's no contract enforcing what type each field must be — the
request is just sent as-is (e.g. as JSON) to the server. The mistake
isn't caught until the request actually reaches the server and
either: the server rejects it with a runtime error (if it validates
input), or worse, the server silently accepts the wrong type and
produces unexpected behavior somewhere downstream, possibly not
surfacing as an obvious error at all.

THE KEY DIFFERENCE: WHEN THE MISTAKE IS CAUGHT
---------------------------------------------------
  - WSDL + generated client: caught before the request is even sent,
    at development/build time.
  - Undocumented REST: caught (at best) after the request has already
    traveled across the network and reached the server, as a runtime
    failure — or possibly not caught at all if the server doesn't
    validate strictly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the real practical payoff of Chapter 5's WSDL section: a
formal, machine-readable contract doesn't just document expected
types, it lets tooling ENFORCE them automatically, moving error
detection as early as possible in the development process — which is
exactly the kind of guarantee enterprise/banking systems value enough
to accept SOAP's extra verbosity in exchange for.