We try to define the right schema/contract for each message/interaction at first, APIs certainly evolve and grow over time, new requirements are introduced, and eventually, also data schema requires changes; hence unlikely we would end up adding a breaking change.
Define the "API Contract" first, if you change the contract, it will impact your consumers.
APIs are mechanisms that enable two software components to communicate with each other using a set of definitions and protocols.
API stands for Application Programming Interface.
- Application refers to any software with a distinct function.
- Interface can be thought of as a contract of service between two applications.
A formal description of an API. E.g. Web Application Description Language (WADL), Web Services Description Language (WSDL), etc. One portion of what a service provider has to offer consumers to enable them to exploit its functionality. A point in time narrow view of a provider, it doesn't form the contract itself.
A formal agreement between parties/services. A document that defines the expected structure (Request, response, path, query parameters, headers, etc.) of an API/Resource by example.
All business capability is exposed through an API, a well-defined set of contracts that allows two or more systems to interact.
- Versioning by URI
- Versioning through DNS
- Versioning through URI Path
- Versioning through Query String
- Versioning by Headers
- Versioning through Content Negotiation
- Versioning through Custom Header
- Versioning by Topic/Exchange
- Versioning by Routing Key
- Versioning by Message Header
- Versioning using Serialization Formats with Central Schema Registry
- Version handling by Message Transformations