Versioning

Crosswork Network Controller offers a set of APIs from one or more Crosswork applications. These applications follow API path-based conventions to manage the versions for each API independently.

API versioning includes the product release version (for example, 7.1.0), an API-specific major version (for example, v1, v2), and the revision date (YYYY-MM-DD).

Example: Product Release: 7.1.0, API Version: v1.0, API Revision: 2025-05-31

API path definition follows the following convention to support path-based version management per API.

Format: http://{host}:{port}/{API-feature}/{API-version}/{API-data-or-operational-resources}

Example: https://{host}:30603/crosswork/nbi/cat-inventory/v1/restconf/operations/cat-inventory-rpc: get-all-services

  • {API-feature}: API-specific feature path name. Example: /crosswork/nbi/cat-inventory
  • {API-version}: API-specific version path. Example: /v1
  • {API-data-or-operational-resources}: API-specific data or operational resources path. Example: /restconf/operations/cat-inventory-rpc: get-all-services

Backward Compatibility

APIs maintain backward compatibility within the same version. If backward incompatibility is necessary, developers introduce it in a newer major version of the API.

Deprecation

APIs follow deprecation policy when there is a backward incompatibility that is introduced by marking the existing API version deprecated and introducing a newer version.