Challenge 1: RPC vs. REST, Revisited — Possible Solution
====================================================================

"GET /users/104" thinks in terms of a RESOURCE — a "user" that exists
as a thing at a specific address (its URL), and the HTTP verb (GET)
describes a generic operation ("fetch") being applied to that
resource. The client isn't calling a function named "get" — it's
asking for the current representation of a specific object.

"call GetUser" thinks in terms of a FUNCTION — a named operation with
its own defined inputs and outputs, closer to calling a method in a
normal program than addressing a resource by URL. The "104" here isn't
part of an address at all — it's simply an argument passed into the
GetUser function/procedure, the same way you'd pass an argument to any
local function call.

Even though both might return the exact same JSON representing user
104, the MENTAL MODEL is different: REST asks "what resource do I
want, and what generic action (GET/POST/PUT/DELETE) am I taking on
it?" while RPC asks "which specific operation do I want to invoke, and
what arguments does it need?" This is exactly the distinction
api-design1-6 drew between REST's resource-based design and RPC's
call-a-named-function design — gRPC is a direct, code-generated,
schema-first version of that same RPC mental model.