Changes and Versioning
The fundamental principle is that you can’t break existing clients, because you don’t know what they implement, and you don’t control them. In doing so, you need to turn a backwards-incompatible change into a compatible one.
Any change to an API MUST NOT break existing clients.
Any change to:
- Resource identifier (resource name / URI) including any query parameters and their semantics
- Resource metadata (e.g. HTTP headers)
- Action the resource affords (e.g. available HTTP Methods)
- Relation with other resources (e.g Links)
- Representation format (e.g. HTTP request and response bodies)
MUST follow the Rules for Extending.
Identifier Stability (No URI Versioning)
A change MUST NOT affect existing resource identifiers (name / URI). Furthermore, a resource identifier MUST NOT contain a semantic version to convey a version of resource or its representation format.
The reason to make a real REST API is to get evolvability … a "v1" is a .... to your API customers, indicating RPC/HTTP (not REST)
Adding a new action to existing resource with identifier
/greeting doesn't change its identifier to
A change to resource identifier, resource metadata, resource actions and resource relations that can't follow the Rules for Extending MUST result into a new resource variant. Existing resource variant MUST be preserved.
A change to representation format SHOULD NOT result into a new resource variant.
Currently, optional URI Query Parameter
first on an existing resource
/greeting?first=John&last=Appleseed needs to be made required. Since this change violates the 3rd rule of extending and could break existing clients a new variant of the resource is created with different URI
Representation Format Changes
A representation format is the serialization format (media type) used in request and response bodies, and typically it represents a resource or its part, possibly with additional hypermedia controls.
If a change can't follow the Rules for Extending the representation format media type MUST be changed. If the media type has been changed the previous media type, MUST be available via Content Negotiation.
If the media type conveys the version parameter, the version parameter SHOULD follow Semantic versioning.
Media type before a breaking change:
Media type after a breaking change:
NOTE: In the case of technical limitations with semi-colon separated HTTP header values, the semantic version MAY be incorporated in the media type identifier, for example:
application/vnd.example.resource.v2+jsonHowever, the use of semicolon-separated version information is preferred.
API Description Versioning
API Description in the OpenAPI specification format MUST have the
version field. The
version field MUST follow Semantic versioning:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner
- PATCH version when you make backwards-compatible bug fixes
The API Description version SHOULD be updated accordingly to API design change.
Following API Description
swagger: '2.0' info: version: '2.1.3' title: '[Demo] Inventory API' description: 'Inventory service API'
Has MAJOR version 2, MINOR version 1 and PATCH version 3.
API description (OAS2) files demonstrating a proposal of an backward-incompatible change turned into a backward compatible change are available at Bitbucket (diff) and documented in Apiary:
- Production version as being consumed by clients
- Development version proposing a backward incompatible change