- To begin operations, a client must know the URI of a Server, for example, https://abiquo.example.com/api
- The system identifies the resources using URIs, for example, https://abiquo.example.com/api/admin/enterprises, where /enterprises/ refers to the collection of enterprises and /enterprises/x refers to a single enterprise.
- From each resource, the Abiquo API links to all of the accessible resources, and a client should reach a resource URI only be by following links from other entities. The client should avoid creating the URI of a resource
- All requests use the Hypertext Transfer Protocol (HTTP), version 1.1 as the transport protocol.
- We do not recommend the use of HTTP Basic Authentication, but the Server can authenticate these requests. If you use them, they should be sent over a secure channel such as a VPN, or using the HTTPS protocol. See Authentication
- Clients must provide a vendor-specific media type for each data entity, for example, if you wanted to send or retrieve an Abiquo tenant, you would use "application/vnd.abiquo.enterprise".
- If clients DO NOT supply a media type, the Abiquo API may return an error or an arbitrary media type (where more than one method uses the same URI and returns different media types)
- Clients can use JSON or XML format for data, and this should be specified after the media type with "+json" or "+xml". If not specified, the "+json" default will be assumed
- Do not try to convert from XML to JSON or vice versa.
- Clients should also provide the version of the data entity (after the media type and the format), for example, "version=4.56"
- If clients DO NOT supply the version of the data entity, the Abiquo API will use the MOST RECENT VERSION of a feature. We STRONGLY RECOMMEND that you always use versions to avoid problems on upgrades.
- Clients should supply the media type of the data entity they are sending with the "Content-Type" header.
- Clients should supply the media type they expect for the response in the "Accept" header.
Example request headers
|title||Example Accept and Content type headers (POST and PUT requests)|
|title||Example of Accept header (GET requests)|
Request parameters include paging parameters for collections of data entities, which are described in this section, and additional query parameters to filter and sort resource data, which are described in the API resource documentation.
To control the number of data entities to retrieve and/or sort entities, in order to improve the user experience, clients can specify the following pagination parameters.
|Parameter Name||Description||Default Value|
|startwith||The first element to be retrieved of the filtered search||0|
|limit||The number of entities to retrieve. To retrieve all entities, use limit = 0||25|
Filter with a text value for specific attributes. See resource documentation
Sort preference. Usually an attribute name. See resource documentation
|Depends on the resource|
|asc||Specifies if the value of the 'by' parameter must be sorted in ascending order (true) or descending order (false)||true|
As described in the default value column, by default the Server filters by retrieving the first 25 entities, starting with the first one, and sorts them in ascending order.
Collection media types may contain multiple data entities. An example of a collection is the "enterprises" media type, in contrast to the "enterprise" media type for a single enterprise.
Collections includeThe collection media type includes:
- A totalSize attribute that is the total number of objects in the resource.
- Pagination links so you can navigate the data entities of the resource.
The error response data model is as follows:
The internal application error code.
The description of the error
For a list of codes and messages, see API Error Code List. For a list of platform events, including actions, tracer messages, and associated error codes, see Events Table.