Design an RPC Abstraction Layer

Design an RPC-style abstraction over hand-written REST calls so application code invokes a local-looking method (e.g. exampleService.processSomething(...)) instead of building HTTP requests by hand. A strong answer covers client/server stubs, marshalling, binding / service discovery, transport hiding, retries with idempotency and duplicate filtering, and interface versioning. What this problem is testing The task is to recognize and design an RPC-style abstraction on top of remote services: the caller thinks in terms of invoking a local-looking method, while a client stub or runtime translates that call into a network request and returns the result as if the procedure had executed locally. What a strong answer covers Client-facing interfaces / generated stubs — a stable method-call surface (hand-written or code-generated) that hides transport from callers. Marshalling / unmarshalling — serialize request arguments and deserialize responses; choose and version the wire format. Binding / service discovery — map a (service, method) name to a concrete network endpoint, and let endpoints move without touching call sites. Transport hidden from callers — REST, gRPC, or another protocol can back the stub without changing application code. Reliability semantics — timeouts, retries, idempotency keys, and duplicate filtering so a retried call is safe. Interface evolution — backward / forward compatibility as services add or change methods (field defaults, deprecation, version negotiation). Notes The client-stub / server-stub split is the crux: the client stub marshals and sends; the server stub unmarshals, dispatches to the real handler, and marshals the reply. Application callers should never see HTTP. Retries make at-least-once delivery the default, so idempotency (dedup keys, idempotent handlers) is what makes the abstraction safe to hide behind a plain method call. Versioning and binding are the two pieces most candidates forget: without a discovery / binding step the "stable interface" leaks endpoints, and without a compatibility story every schema change breaks callers.