Challenge 3: Choosing Within the RPC Family — Possible Solution
====================================================================

(a) Integrating with a 15-year-old legacy system that only speaks an
    older RPC format
    -> RECOMMEND: XML-RPC.
    Justification: if the existing system was built around XML-RPC
    specifically and can't be changed, there's no real choice here —
    you integrate with whatever it actually speaks. This is exactly
    the "mostly legacy" status this chapter's table assigned to
    XML-RPC: it's rarely chosen for something NEW today, but it's
    still worth understanding because plenty of older systems out
    there genuinely still use it, and this is a textbook case of that.

(b) A new internal microservice needing very high-throughput,
    low-latency binary communication with strict typing
    -> RECOMMEND: gRPC.
    Justification: this scenario explicitly asks for exactly what
    gRPC is built for — binary Protocol Buffers instead of
    text-based JSON/XML (faster to serialize/parse and smaller over
    the wire), HTTP/2 as a modern high-performance transport, and a
    formal, enforced contract (the .proto file) giving strict typing
    the way WSDL did for SOAP, but far lighter weight. Neither
    XML-RPC nor JSON-RPC offers binary encoding or a built-in formal
    contract, so gRPC is the clear fit for this specific set of
    requirements.

(c) A small hobby project's simple JSON-based API between two of your
    own scripts
    -> RECOMMEND: JSON-RPC.
    Justification: for a small, low-stakes project where you control
    both ends, JSON-RPC's simplicity is the right fit — it's easy to
    implement by hand, JSON is natively supported almost everywhere,
    and you don't need gRPC's extra tooling (code generation, .proto
    files, HTTP/2 setup) or XML-RPC's XML parsing overhead for
    something this small.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each answer follows directly from this chapter's comparison table:
XML-RPC for legacy compatibility with no real alternative, JSON-RPC
for lightweight simplicity when the stakes and scale are small, and
gRPC when performance, binary efficiency, and strict typing are
actual hard requirements rather than nice-to-haves. The "right"
choice in the RPC family, just like REST vs SOAP in earlier
chapters, depends entirely on which specific properties the situation
actually needs.