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 field
Well-behaved clients should tolerate unknown fields.
Usually breaking: Remove response field
Existing clients may depend on the field.
Usually breaking: Change string to object
The client's expected type changes.