What are backward compatibility strategies and Postel's Law in REST API evolution?

Postel's Law (the Robustness Principle): "Be conservative in what you send, be liberal in what you accept." For APIs: ignore unknown request fields gracefully (do not reject requests with extra fields), but always return well-formed, conservative responses. Key backward-compatible (non-breaking) changes: adding new optional fields to responses (clients ignore unknown fields), adding new optional request parameters with sensible defaults, adding new endpoints, and loosening validation. Breaking changes: removing fields, renaming fields, changing field types, making optional fields required, or changing URL structure. Strategies to avoid breaking changes: use additive-only changes for the life of a version, use deprecation headers (Deprecation: true, Sunset: Sat, 01 Jan 2027 00:00:00 GMT) to warn clients before removal, and use expansion patterns — add new fields alongside old ones (amount and amountInCents) during transition. Monitor field-level usage analytics to know when it is safe to remove deprecated fields.