How Does a Schema Language Shape an RPC Interface?
From the earlier reference collection. Read the current software blog.
An RPC schema becomes a long-lived agreement between clients and servers. Field identity, defaults, and evolution rules determine whether new software can communicate with older peers.
A schema defines the message contract
An RPC call crosses a boundary between separately running programs. The schema describes what a request and response contain, how values are represented, and how a method is named. Client and server code can then be generated or checked against that shared description.
This makes a schema more than a convenient serialization format. Once software is deployed, different versions may coexist. A phone app can remain installed while a server changes, or a device can be offline during an upgrade. The interface must account for those mismatched timelines.
Field identifiers should be stable
Many schema formats assign identifiers or tags to fields. The wire representation can use those identifiers to distinguish values, so changing a field’s source-code name may be safe in some designs while reusing its identifier for a different meaning is not. A client could interpret the old value as the new concept and produce plausible but incorrect behavior.
Consider a request with field 1 for a station identifier and field 2 for a time range. If a later version removes the time range, a new field should not casually reuse identifier 2 for a user preference. Keep a record of retired identifiers and the compatibility rules of the chosen schema system.
Defaults influence old and new peers
A default can make an omitted field behave as though it had a known value. That helps when an older sender does not know about a newer optional field. But the default itself becomes part of the contract: changing its meaning can alter how old data is interpreted by new code.
For example, an optional include_archived setting might default to false. If a later client assumes omission means true, messages from older clients become ambiguous. Prefer defaults whose meaning is stable, and document whether absence, an explicit default value, and an unknown value are distinct.
Plan evolution before deployment
Before adding or changing a field, ask whether old clients can ignore it, whether new clients can tolerate its absence, and whether the wire format preserves unknown data when forwarding messages. These properties vary by schema language and generated runtime; confirm them in the system’s actual documentation rather than assuming a universal rule.
A safe interface evolves through small, compatible changes and tests across the versions that will coexist. Treat field identifiers, defaults, and removal policy as design decisions that deserve review. The schema then serves as a durable agreement instead of a snapshot of one release.