When making GET calls, users can specify an optional parameter, "selector." The selector allows filtering of the returned response body to contain only specific key-value pairs. The selector options are:
Retrieves key-value pair attributes associated with configuring the Resource
Retrieves key-value pair attributes associated with health status of the device
Retrieves key-value pair attributes associated with device statistics
Retrieves key-value pair attributes associated with attributes that are mutable
The "depth" parameter allows expanding nested URIs to show the key-value pairs of those resources in JSON responses.
For a given depth 'n', if the response contained URIs, then a depth of 'n+1' would receive a response with the full bodies of the resources for the previous URIs. Consequently, if the response for 'n+1' contained URIs, then a depth of 'n+2' would expand the bodies of the resources within 'n+1' responses.
Depth is a non-negative integer value, and in REST API v10.04 the default value is 1.
For example, here is a GET call for VLANS with v10.04 with "depth" set to 1:
Comparatively, below is the same call with "depth" set to 2. Note that the VLAN 1 is expanded to show the results as if a GET was pointing to the URI of VLAN 1. After VLAN 1, the response would continue to show the expanded info for VLANs 255, 2020, etc.
In REST API v10.04, the default depth value is 1. In the v1 API, it is 0.
When using the REST API for workflows, the PUT method is used to update information in a resource. However, if an attribute in the JSON is not included in the PUT request body, it quite possibly may be changed to the default setting.
In order to easily create the PUT body without needing to manually include each attribute, first perform a GET on the URI and save the response, and then use that data for the PUT. It is especially useful to execute the GET with the selector as 'writable', as that will return only the key-value pairs whose values can be changed.
Methods (PUT / POST)
Logging into an API session
Logging out of an API session
Managing NAE scripts
POST and PUT
As of firmware version 10.05, the maximum number of concurrent HTTPS sessions per user per switch is six. There is an upper limit of 48 total sessions per switch. It is best practice to log out of an HTTPS session when you are finished using it.
HTTPS sessions will automatically time out after 20 minutes of inactivity.
HTTPS sessions also have a hard time limit of eight hours, regardless of whether the session is active.
To close all current HTTPS sessions, run the following command in the enable (#) context:
8320# https-server session close all
Prior to firmware version v10.05, the maximum number of concurrent HTTPS sessions per user per switch is three.
Updated over 2 years ago