Versioning, Validation, and Error Design
A stable contract makes compatibility explicit. Prefer additive changes when possible: adding an optional response field is often safer than renaming a field that existing clients depend on. Removing fields, changing meanings, or tightening validation can be breaking changes even when the URL stays the same.
Validate untrusted input at the boundary: types, lengths, ranges, allowed enum values, object shape, and ownership. Validation prevents malformed data from reaching deeper layers, but authorization must still check whether the caller may access the referenced object.
Return consistent machine-readable errors with a stable code, safe message, and correlation identifier. Do not expose stack traces, database errors, secrets, or internal topology to public clients. Maintain an API deprecation policy and measure usage before removing old versions.
- Compatibility includes behavior and semantics, not just JSON shape.
- Validate input and separately authorize access.
- Errors should help clients recover without revealing sensitive internals.