vCloud API REST Requests

To retrieve object representations, clients make HTTP requests to object references. The server supplies these references as href attribute values in responses to GET requests.

Every vCloud Director installation has a well-known URL from which an unauthenticated user can retrieve a SupportedVersions document, which lists each version of the vCloud API that the server supports. For each version, the response lists the names and MIME types of the complex types defined in the version's XML namespace, and the version login URL. A system administrator can use that URL to authenticate to the cloud by logging in to the System organization. An authenticated user can discover other vCloud API URLs by making GET requests to URLs retrieved from the login response, and the URLs contained in responses to those requests. See Exploring a Cloud.

Requests are typically categorized by the type of requested operation: create, retrieve, update, and delete. This sequence of verbs is often abbreviated with the acronym CRUD. Each type of request is characterized by the use of specific HTTP verb to access a URL found in a Link element that has an operation-specific value for its rel (relation) attribute.

CRUD Operations Summary
Operation Type	HTTP Verb	Link Relation	Operation Summary
Create	POST	add	Creates a new object.
Retrieve	GET	down	Retrieves the representation of an existing object in its current state.
Update	PUT	edit	Modifies an existing object.
Delete	DELETE	remove	Deletes an existing object. If the object is a container, you must remove all of its contents before you can delete it.

For example, this Link element indicates that you can use the URL https://vcloud.example.com/api/admin/org/26 to update the Org object that contains it.

<Link
   rel="edit"
   type="application/vnd.vmware.admin.organization+xml"
   href="https://vcloud.example.com/api/admin/org/26" />

The implied HTTP verb is PUT.

Important

Request bodies must contain all required elements and attributes, even if you are not changing their values. Because optional elements and attributes typically revert to default values if they are omitted or empty, it is a best practice to include optional elements in request bodies that modify existing objects. Link elements and href attributes from responses do not need to be included in modified sections. Some elements and attributes are read-only and cannot be modified. See the schema reference for details.

Security

HTTP communications between a vCloud API client and server are secured with SSL. API clients must also complete a login request to receive an authorization token that must be included in all subsequent requests.

Request Headers

The following HTTP headers are typically included in vCloud API requests:

Accept	All requests must include an HTTP `Accept` header that designates the vCloud API version that the client is using. Two forms of this header are supported: Accept: application/;version=`api-version` Accept: application/vnd.vmware.vcloud.`type`+xml;version=`api-version` The second form constrains acceptable responses to a `type` defined the vCloud API schema. For example, the following header indicates that the request is from a vCloud API version 5.6 client, and will accept any type defined in that API version: Accept: application/;version=5.6 In general, client requests can access objects defined by any version of the vCloud API that is less than or equal to the version specified in the `Accept` header. See API Versions. Note `Accept` headers of the following form are also allowed in vCloud API requests, but they are not compliant with RFC 2616 and might be rejected by future versions of the vCloud API. Accept: application/*+xml;version=`api-version`
Accept-Encoding	By default, the system returns response content as uncompressed XML. Compressing the response can improve performance, especially when the response is large and network bandwidth is a factor. (Requests cannot be compressed.) To request a response to be returned as compressed XML, include the following header: Accept-Encoding: gzip The response is encoded using gzip encoding as described in RFC 1952, and includes the following header: Content-Encoding: gzip In the default configuration, responses smaller than 64KB are never compressed.
Accept-Language	Message strings in ErrorType responses are localized. To specify the language desired in responses, use the `Accept-Language` request header. To request a response with message strings localized to French, use the following header: Accept-Language: fr
Authorization	All requests to create a vCloud API session must include an `Authorization` header of the form prescribed by the identity provider that your organization uses. See Create a vCloud API Session.
Content-Type	Requests that include a body must include an appropriate HTTP `Content-Type` header. Content types for all elements are listed in the schema reference. In addition, the type attribute of a response body indicates the content type of the document. For example, this response fragment indicates that the content type associated with a CatalogItem object is application/vnd.vmware.vcloud.catalogItem+xml. <CatalogItem type="application/vnd.vmware.vcloud.catalogItem+xml" name="Ubuntu Template with vsftpd" ... /> A POST or PUT request that supplies a CatalogItem in the request body requires the following `Content-Type` header: Content-Type: application/vnd.vmware.vcloud.catalogItem+xml When it appears as the value of a `Content-Type` header or the type attribute of an element in the vCloud API, this string is case-insensitive in requests, and can be returned in either mixed case or lowercase characters in responses.
x-vcloud-authorization	This header, which is returned with the Session response after a successful log-in, must be included in all subsequent requests from clients that authenticate to the integrated identity provider (see Create a Session Using Basic Authentication) or the SAML identity provider (see Create a Session Using SAML Authentication). Note Clients that authenticate to the OAuth identity provider can include either the `x-vcloud-authorization` header or the OAuth `Authorization: Bearer` header to authorize a request. See Create a Session Using OAuth Authentication.
X-VMWARE-VCLOUD-CLIENT-REQUEST-ID	The value of this header is used to build a request ID returned in the value of the X-VMWARE-VCLOUD-REQUEST-ID header (see Response Headers). The value of this header cannot contain more than 128 characters drawn from the set of letters, numbers, and the hyphen (-). Values with invalid characters are ignored. Values with more than 128 characters are truncated.

Request Bodies

vCloud Director uses a validating XML parser that requires elements in a request body to agree with the schema in order and number. Request bodies are rejected as invalid unless they meet the following criteria:

■	XML namespace attributes must be supplied for all namespaces represented by elements in the request. See XML Namespace Identifiers.
■	If multiple namespaces are represented in the request, XML namespace attributes must include an identifying prefix, and that prefix must be used with all elements from that namespace.
■	All required elements must appear in request bodies. All elements that appear in request bodies must appear in the order that the schema establishes, and with content that conforms to the type constraint that the schema specifies.

Request Limits

To guard against denial-of-service attacks, vCloud Director imposes the following limits on vCloud API requests:

■	Requests cannot exceed 512 KB.
■	Requests cannot contain more than 4096 XML elements.
■	Requests cannot have a depth greater than 100.