Breaking vs Non-Breaking Changes
API Evolution
Breaking changes can include removing fields, changing field types, changing semantics, removing enum values, changing authentication behavior, making optional inputs mandatory, or changing status-code behavior clients rely upon.
Non-breaking changes commonly include adding optional request fields and adding response fields when clients are designed to ignore unknown fields.
Compatibility must be evaluated from the perspective of real consumers, not only server code.
Compatibility
Usually safe:
Add optional response fieldWell-behaved clients should tolerate unknown fields.
Usually breaking:
Remove response fieldExisting clients may depend on the field.
Usually breaking:
Change string to objectThe client's expected type changes.