Service Versions

Each service has a version number as part of the Uniform Resource Identifier (URI) to access the service. The version has a major and minor number. Requests must supply the major version number but the minor version number is optional and defaults to a value of "0" if not supplied. The major number must match the major number of the service. The minor number must be less than or equal to the minor number of the service.

Example: A client makes some requests for a service that is running version number “2.1”.

No service API version changes are required for the following property changes. The appliance version number and model must be used to determine which properties are available. These property changes are also re?ected in the CLI and BUI and are an indication of the capabilities of that ZFSSA instance.  

• New output properties (without removing old properties).

• New input properties added to an existing command, that have default values that make the command behave is it did in an earlier version.

Since a newer version of a backwards-compatible command can return additional properties, clients should be coded to ignore new properties. The minor number is incremented for backwards-compatible changes to the service API.

• Add a new command to an existing service.

• Add new query parameters to service commands.

The major number is incremented with incompatible changes to the service API.

• Removing command query parameters.

• Removing a command from an existing service.

Major releases of ZFSSA software may include incompatible version changes. There may or may not be older versions of a given service during a major update. Each command response must contain an HTTP header with the current version of the ZFSSA API for a given module:  

X-Zfssa-Nas-Api:  1.1