| Table of Contents |
|---|
...
- Implement semantic versioning (MAJOR.MINOR.PATCH) for APIs
- If necessary, refactor APIs to support the concept of MINOR releases; versioning scope and use cases provided
- Adopt a BWC policy for APIs that is current MAJOR release minus 1 year (to be re-visited post-Casablanca)
HTTP/REST API specific rules/policies:
...
- API BWC shall be defined for MAJOR releases as the current release - 1 year (to be re-visited post-Casablanca). In other words, if an API is currently at 1.12 and a MAJOR release occurs to increment the version to 2.0, 1.12 (which is BWC for versions 1.0-1.11) must be functional/available for the period of 1 year after 2.0 is released.
- API owners shall ensure the previous MAJOR release remains available and functioning, in its last available production state, for the period of the BWC policy.
- MINOR releases shall be not time or release-based, as they are assumed to be BWC.
- API owners shall ensure no end-to-end services break with the deprecation of an API, due to the BWC Policy. End-to-end services includes, but is not limited to, VNFs, PNFs, Networks, Allotted Resources, etc.
...
- REST APIs Must be Hypertext-Driven: Blog post where Roy Fielding argues that not any HTTP-based interface is a REST API
- RESTful API Design Specification (for ONAP)
- REST APIs don’t need a versioning strategy – they need a change strategy