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.
For example, the following table shows whether the specified versions could be used in a client request if the client is requesting a service that is running version 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 reflected in the CLI and BUI and are an indication of the capabilities of that appliance 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 appliance 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 appliance API for a given module:
X-Zfssa-Nas-Api: 1.1