API changes
Code accessing our API should not break if an API endpoint starts to return responses containing additional fields. Such changes could be made by Voyado without warning as part of our normal development so you need to be ready for them. Breaking changes will be flagged early, giving you adequate time to prepare.
Common non-breaking changes
Adding an optional field to a request message. Existing client code will not be forced to use the new field.
Adding a required field with a default value to a request message. The server will add the default value if the client does not send it.
Adding a field to a response message. Existing client code should ignore any such new fields. Do not implement a mapping that raises an error for new fields.
Caution
Write code that will not break if additional fields are added to responses.
Common breaking changes
Renaming fields or resource paths in a way that requires client code to change.
Renaming or removing fields in a request or response message.
Removing API operations used by existing clients of the API.
Changing fields from single value to multiple value (like from a single email per member to a list of email addresses).
Changing the HTTP method or the response codes returned by an API operation.