NSX VMC Policy v1.0

Introduction

NSX-T Data Center provides a programmatic API to automate management activities. The API follows a resource-oriented Representational State Transfer (REST) architecture, using JSON object encoding. Clients interact with the API using RESTful web service calls over the HTTPS protocol.

Each API method is identified by a request method and URI. Method parameters are specified as key-value pairs appended to the URI. Unless otherwise noted, request and response bodies are encoded using JSON, and must conform to the JSON schema associated with each method. The content type of each request and reply is “application/json” unless otherwise specified. Each request that can be made is documented in the API Methods section. The associated request and response body schemas are documented in the API Schemas section.

Some APIs may be marked as deprecated. This indicates that the functionality provided by the API has been removed or replaced with a different API. The description of the API will indicate what API(s) to call instead.

Some APIs may be marked as experimental. This indicates that the API may be changed or removed without notice in a future NSX-T Data Center release.

It is possible for any request to fail. Errors are reported using standard HTTP response codes. It should be assumed the following errors could be returned by any API method: 301 Moved Permanently, 307 Temporary Redirect, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 500 Internal Server Error, 503 Service Unavailable. Where other errors may be returned, the type of error is indicated in the API method description. All errors are documented in the API Errors section.

Request Authentication

Most API calls require authentication. This API supports HTTP Basic authentication and session-based authentication schemes. Multiple authentication schemes may not be used concurrently.

HTTP Basic Authentication

To authenticate a request using HTTP Basic authentication, the caller’s credentials are passed using the ‘Authorization’ header. The header content should consist of a base64-encoded string containing the username and password separated by a single colon (":") character, as specified in RFC 1945 section 11.1.

For example, to authenticate a request using the credentials of user admin with password admin, include the following header with the request:

Authorization: Basic YWRtaW46YWRtaW4=

The following cURL command will authenticate to the manager using basic authentication and will issue a GET request for logical ports:

curl -k -u USERNAME:PASSWORD https://MANAGER/api/v1/logical-ports

Where

1. USERNAME is the user to authenticate as,
2. PASSWORD is the password to provide, and
3. MANAGER is the IP address or host name of the NSX manager

For example:

curl -k -u admin:secretPw99 https://192.168.22.32/api/v1/logical-ports

Note: the -k argument instructs cURL to skip verifying the manager’s self-signed X.509 certificate.

Authenticating to vIDM

When NSX-T is configured to use VMware Identity Manager (vIDM) for authentication, you supply an Authorization header with an authentication type of “Remote”. Te header content should consist of a base64-encoded string containing the username@domain and password separated by a single colon (":") character, as specified in RFC 1945 section 11.1. For example, to authenticate a request using the credentials of user jsmith@example.com with password Sk2LkPM!, include the following header with the request:

Authorization: Remote anNtaXRoQGV4YW1wbGUuY29tOlNrMkxrUE0h

The following cURL command will authenticate to the manager using basic authentication and will issue a GET request for logical ports:

curl -k -H "Authorization: Remote BASE64" https://MANAGER/api/v1/logical-ports

where:

• BASE64 is the base64-encoded string containing the username@domain and password separated by a single colon (":"), and
• MANAGER is the IP address or host name of the NSX manager

For example:

curl -k H "Authorization: Remote anNtaXRoQGV4YW1wbGUuY29tOlNrMkxrUE0h" https://192.168.22.32/api/v1/logical-ports

Note: the -k argument instructs cURL to skip verifying the manager’s self-signed X.509 certificate.

Session-Based Authentication

Session-based authentication is used by calling the /api/session/create authentication API to manage a session cookie. The session cookie returned in the result of a successful login must be provided in subsequent requests in order to associate those requests with the session.

Session state is local to the server responding to the API request. Idle sessions will automatically time-out, or can be terminated immediately using the POST /api/session/destroy API.

To obtain a session cookie, POST form data to the server using the application/x-ww-form-urlencoded media type, with fields “j_username” and “j_password” containing the username and password separated by an ampersand. Since an ampersand is a UNIX shell metacharacter, you may need to surround the argument with single quotes.

The following cURL command will authenticate to the server, will deposit the session cookie in the file “cookies.txt”, and will write all HTTP response headers to the file headers.txt. One of these headers is the X-XSRF-TOKEN header that you will need to provide in subsequent requests.

curl -k -c cookies.txt -D headers.txt -X POST -d 'j_username=USERNAME&j_password=PASSWORD' https://MANAGER/api/session/create

For example:

curl -k -c cookies.txt -D headers.txt -X POST -d 'j_username=admin&j_password=secretPw99' https://192.168.22.32/api/session/create

The manager will respond with the roles and permissions granted to the user, and cURL will deposit the session cookie into the file “cookies.txt”.

In subsequent cURL requests, use the -b argument to specify the cookie file. You also need to pass the X-XSRF-TOKEN header that was saved to the headers.txt file, using cURL’s -H option:

curl -k -b cookies.txt -H "`grep X-XSRF-TOKEN headers.txt`" https://192.168.22.32/api/v1/logical-ports

When the session expires, the manager will respond with a 403 Forbidden HTTP response, at which point you must obtain a new session cookie and X-XSRF-TOKEN.

Session cookies can be destroyed by using the /api/session/destroy API:

curl -k -b cookies.txt -H "\`grep X-XSRF-TOKEN headers.txt\`" -X POST https://MANAGER/api/session/destroy

Example Requests and Responses

Example requests and responses are provided for most of the API calls below. Your actual response might differ from the example in the number of fields returned because optional empty fields are not returned when you make an API call.

Restrictions on Certain Fields in a Request

When configuring layer 2 switching, the following fields can contain any character except semicolon (;), vertical bar (|), equal sign (=), comma (,), tilde (~), and the “at” sign (@). They also have a length limitation as specified below:

• Logical switch display name. Maximum length: 80 bytes.
• Host switch name in TransportZone. Maximum length: 80 bytes.
• Uplink name in UplinkHostSwitchProfile. Maximum length: 47 bytes.

Optimistic Concurrency Control and the _revision property

Overview

In order to prevent one client from overwriting another client’s updates, NSX-T employs a technique called optimistic concurrency control.

All REST payloads contain a property named “_revision”. This is an integer that is incremented each time an existing resource is updated. Clients must provide this property in PUT requests and it must match the current _revision or the update will be rejected. This guards against the following situation:

Client 1 reads resource A.

Client 2 reads resource A.

Client 1 replaces the display_name property of resource A and does a PUT to replace the resource.

Client 2 replaces is different property of resource A and attempts to perform a PUT operation.

Without optimistic concurrency control, Client 2’s update would overwrite Client 1’s update to the display_name property. Instead, Client 2 receives a 409 Conflict error. To recover, Client 2 must fetch the resource again, apply the change, and perform a PUT.

Exceptions for /policy APIs

APIs whose URI begins with /policy have slightly different behavior. For those APIs, the _revision property must not be set when PUT is used to create a new resource. Once the resource is created, however, the _revision property must be provided with PUT operations.

PATCH and _revision for /policy APIs

APIs whose URI begins with /policy support the PATCH operation. Those APIs do not require that the _revision property be provided. A client can, however, request that the _revision property be checked when it is performing a PATCH in the /infra path. To do this, the client should pass the query parameter enforce_revision_check, e.g. PATCH /infra?enforce_revision_check=true.

OpenAPI Specification of NSX-T Data Center API

You can get an OpenAPI specification of the NSX-T Data Center API with one of the following calls:

• GET https://MANAGER/api/v1/spec/openapi/nsx_api.yaml
• GET https://MANAGER/api/v1/spec/openapi/nsx_api.json