Response Format
API HTTP response messages use standard HTTP response codes to designate high-level status (success, failure, etc.) and simple XML payload in the response body to provide additional method specific data or specific error messages.
HTTP Response Codes
Zend Server Web API operations will return standard HTTP response codes in order to indicate overall success or failure. In case of an error, the HTTP status code may further indicate the nature of the problem, and a specific error code contained in the response body will indicate the specific nature of the error.
The following HTTP response codes may be used:
- 200 OK - The operation has completed successfully.
- 202 Accepted - The operation was accepted and is being processed, but is not complete yet.
- 4xx - HTTP status codes between 400 and 499 are used to designate a client-side error. For example, a missing request parameter or an authentication error.
- 5xx - HTTP status codes between 500 and 599 are used to designate a server-side error. For example, a temporary locking issue or an unexpected error in the server operation.
Additional information about HTTP response codes for error responses is available in Error Responses, as well as in the documentation for each method.
HTTP Response Headers
The following HTTP response headers will be included in API responses:
- Content-type - Unless stated otherwise, these will be “application/vnd.zend.serverapi+xml; version=<API version>”. For more information about API versions see API Versioning Negotiation.
HTTP Response Body
The Web API HTTP response body will almost always contain an XML document of the following format:
<?xml version="1.0" encoding="UTF-8"?>
<zendServerAPIResponse ><requestData>
<apiKeyName>angel.eyes</apiKeyName>
<method>clusterGetServerStatus</method>
</requestData>
<responseData>
[response data here...]
</responseData>
</zendServerAPIResponse>
All API responses are enclosed in <zendServerAPIResponse> tags, and contain two sections: <requestData> which includes some reference information about the request; and <responseData> which includes the response data.
The content of the <responseData> section differs depending on the specific method called. Refer to the method's specific documentation for additional information.
In error responses, the <responseData> section is replaced with an <errorData> section. See Error Responses for additional information.
Some Web API methods will not return an XML document in case of a successful operation - specifically, methods that export large amounts of binary data such as the configurationExport method. In such cases, this is specifically indicated in the method's documentation. Note that you can check the value of the Content-type response header in order to know in advance what kind of content to expect in the response.
Error Responses
In a response representing an error, the <responseData> XML section is replaced with the <errorData> XML section, which has the following format:
<errorData>
<errorCode>serverDoesNotExist</errorCode>
<errorMessage>A server with the specified ID does not exist in the cluster</errorMessage>
</errorData>
Where:
- <errorCode> is a short alphanumeric constant string that represents the specific error.
- <errorMessage> is a human readable, native language explanation of the error.
In addition, some error responses may include additional elements in the <errorData> container, with additional information relevant to the specific error.
Generic Error Codes
The following generic error responses are possible for any operation:
HTTP Code |
Error Code |
Description |
400 |
missingHttpHeader |
A required HTTP header is missing. |
400 |
unexpectedHttpMethod |
An unexpected HTTP method where GET is used but POST is expected. |
400 |
invalidParameter |
One or more request parameters contains invalid data. |
400 |
missingParameter |
The request is missing a required parameter. |
400 |
unknownMethod |
An unknown Zend Server API method. |
400 |
malformedRequest |
The server is unable to understand the request. |
401 |
authError |
An authentication error occurred because of an unknown key or invalid request signature. |
401 |
insufficientAccessLevel |
The user is not authorized to perform this action. |
401 |
timeSkewError |
The request timestamp deviates too much from the server time. |
405 |
notImplementedByEdition |
The method is not implemented by this edition of Zend Server. |
406 |
unsupportedApiVersion |
The API version is not supported by this version of Zend Server. |
500 |
internalServerError |
An unexpected error occurred on the server side. |
500 |
serverNotConfigured |
This Zend Server installation was not yet initialized (the user did not go through the initial setup wizard). |
500 |
serverNotLicensed |
Zend Server does not have a valid license, which is required to perform this operation. |
Refer to the documentation of a specific method for details about additional possible errors specific to each method.