What can and cannot be done when designing an API to maintain backward compatibility?

When designing an API to maintain backward compatibility, it is important to:

What can be done:

• Add new fields or endpoints without removing old ones.
• Use optional parameters instead of mandatory ones.
• Version the API (e.g., through URLs or headers).
• Handle unknown fields on the client and server sides without errors.

What cannot be done:

• Remove or rename existing fields and methods.
• Change data types of existing fields.
• Alter API behavior in a way that breaks existing client logic.
• Break the contract, for example, by changing the mandatory nature of parameters.

Thus, new API versions should be extensible, and old clients should continue to work without changes.