NX-API REST brings Model Driven Programmability (MDP) to the Cisco Nexus 9000 series switch in standalone mode (i.e. Not Cisco ACI mode and non-APIC managed). The NX-API REST model borrows several concepts from Cisco ACI and makes them available for non-ACI based standalone Nexus fabric environment. In model-driven architectures, software maintains a complete, explicit representation of the administrative and operational state of the system (the model). This object model is made available through standard Representational State Transfer (REST) interfaces, making it easier to access and manipulate the object model, and hence, the configuration and runtime state of the system.
In the Cisco NX-API REST framework, configuration and state information of the switch is stored in a
hierarchical tree structure known as the management information tree (MIT), which is accessible through
the API. One can make changes on a single object or an object subtree. Each node in the MIT represents a
managed object (MO) and are organized in a hierarchical way. Every MO in the system can be identified by
a unique distinguished name (DN). Another type of object are classes. Classes are a combination of packages
and methods. You see these annotated as package:method. For example, boot:Image.
You will see this particular class later in this section.
The MOs have parent-child relationships that are identified using DNs and properties, which are read and modified by a set of create, read, update, and delete (CRUD) operations, mentioned in the opening of this lab section:
| VERB | CRUD | Description |
|---|---|---|
| POST | Create | The POST verb is mostly used for creation of a new entity or service on the the ReST server |
| GET | Read | The GET verb is the most common verb and is used to retrieve information from the ReST server |
| PUT | Update/Replace | The PUT verb is utilized for updating resources in the ReST server API. |
| DELETE | Delete | As the name states, it deletes the specified resource that is invoked. |
The URL format used can be represented as follows:
This is definitely a different way of thinking. Additional resources for learning NX-API REST can be found below. The NX-API REST Reference provides a little further background into the MIT and examples, much like the examples you are going to glean from using the NX-API Sandbox. The second reference, NX-API DME (Data Management Engine) Model Reference is very promising for being able to find the classes. Note, this was derived from ACI and is a work in progress. Again, sticking with the NX-API Sandbox and leveraging the knowledge of configuration commands you already have is what you'll be doing in this lab.
Example NX-API REST OSPF Object:
{
"topSystem": {
"children": [
{
"ospfEntity": {
"children": [
{
"ospfInst": {
"attributes": {
"name": "UNDERLAY"
},
"children": [
{
"ospfDom": {
"attributes": {
"name": "default"
}
}
}
]
}
}
]
}
}
]
}
}
In the NX-API Sandbox, click the Reset button.
In the NX-API Sandbox web application:
On the N9Kv, the convert operation may take a couple of minutes, please be patient while this task completes.
If your CLI command is incorrect in anyway, the Response: box would be populated instead of the Request: box and it would contain an error indicating the issue.
The generated request is found below. Again, this is JSON and like you did for NX-API CLI, lets understand the key, value pairs a little better. topSystem is the class that is top of the tree, closest to the Root of the tree. Continuing down the hierarchical tree is a child bootBoot class with topSystem being the parent. Again, you find another parent/child relationship between bootBoot and the next class in the tree, bootImage that contains configuration attributes.
After converting your cli, you can see this is an easy way to obtain the object model (DME model) and use in a more programmetic way. If you wish to send via the Sandbox, after converting, simply click Send.
Request:
{
"topSystem": {
"children": [
{
"bootBoot": {
"children": [
{
"bootImage": {
"attributes": {
"sup1": "bootflash:/nxos.9.3.13.bin",
"sup2": "bootflash:/nxos.9.3.13.bin"
}
}
}
]
}
}
]
}
}
At this point, you have been exposed to utilizing the NX-API Sandbox to understand the different message formats that leverage the JSON data structure to perform request operations using NX-API. Continue to the next section to examine NX-API with Python.