Versions Compared

Old Version 31

changes.mady.by.user Dana Bobko

Saved on

compared with

New Version 32

changes.mady.by.user Dana Bobko

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added note to BWC

Table of Contents
Executive Summary

...

1 PATCH refers to the position in the version number, not the HTTP method of PATCH. This method should not be used as it is idempotent.

Backward Compatibility (BWC) Policy - TO BE REVISITED DURING OR POST-CASABLANCA

  • 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.

...

  1. REST APIs Must be Hypertext-Driven: Blog post where Roy Fielding argues that not any HTTP-based interface is a REST API
  2. RESTful API Design Specification (for ONAP)
  3. REST APIs don’t need a versioning strategy – they need a change strategy