RESTCONF API

RESTCONF provides a programmatic interface for reading and writing network device configurations through NSO. Platform workflows interact with the NSO RESTCONF API using the restAction task.

NSO RESTCONF support

NSO also supports JSON-RPC and NETCONF. See Cisco NSO developer documentation for Swagger API documentation and additional protocol references.

HTTP methods

Method values are case-insensitive.

The restAction task

Use the restAction task in a workflow to make RESTCONF calls to NSO. The task handles authentication and connection routing through the configured NSO adapter.

Incoming variables

Outgoing variables

params object

1
{
2
  "path": "/restconf/data/tailf-ncs:devices/device=C-IOS1",
3
  "contentType": "application/yang-data+json",
4
  "accept": "application/yang-data+json",
5
  "method": "GET"
6
}

Examples

The following examples show complete restAction variable inputs for each HTTP method. In each example, adapterId is set to "Local NSO" — substitute the name of your configured adapter instance.

GET — read a device

Retrieve device information for C-IOS1:

1
adapterId: "Local NSO"
2
3
params: {
4
  "path": "/restconf/data/tailf-ncs:devices/device=C-IOS1",
5
  "contentType": "application/yang-data+json",
6
  "accept": "application/yang-data+json",
7
  "method": "GET"
8
}
9
10
body: {}

PATCH — update device configuration

Add a loopback interface configuration to C-IOS1:

1
adapterId: "Local NSO"
2
3
params: {
4
  "path": "/restconf/data/tailf-ncs:devices/device=C-IOS1/config",
5
  "accept": "application/yang-data+json",
6
  "contentType": "application/yang-data+json",
7
  "method": "PATCH"
8
}
9
10
body: {
11
  "config": {
12
    "tailf-ned-cisco-ios:interface": {
13
      "Loopback": [
14
        {
15
          "name": "1",
16
          "ip": {
17
            "address": {
18
              "primary": {
19
                "address": "127.0.0.1",
20
                "mask": "255.0.0.0"
21
              }
22
            }
23
          }
24
        }
25
      ]
26
    }
27
  }
28
}

PUT — replace a configuration resource

Replace the IP address configuration on loopback interface 1 of C-IOS1:

1
adapterId: "Local NSO"
2
3
params: {
4
  "path": "/restconf/data/tailf-ncs:devices/device=C-IOS1/config/tailf-ned-cisco-ios:interface/Loopback=1/ip",
5
  "accept": "application/yang-data+json",
6
  "contentType": "application/yang-data+json",
7
  "method": "PUT"
8
}
9
10
body: {
11
  "ip": {
12
    "address": {
13
      "primary": {
14
        "address": "127.0.0.2",
15
        "mask": "255.0.0.0"
16
      }
17
    }
18
  }
19
}

POST — create a device

Add a new device named C-IOS1 to NSO:

1
adapterId: "Local NSO"
2
3
params: {
4
  "path": "/restconf/data/tailf-ncs:devices",
5
  "contentType": "application/yang-data+json",
6
  "accept": "application/yang-data+json",
7
  "method": "POST"
8
}
9
10
body: {
11
  "tailf-ncs:device": {
12
    "name": "C-IOS1",
13
    "address": "127.0.0.1",
14
    "port": 10022,
15
    "authgroup": "default",
16
    "device-type": {
17
      "cli": {
18
        "ned-id": "cisco-ios-cli-6.23:cisco-ios-cli-6.23"
19
      }
20
    }
21
  }
22
}

DELETE — remove a device

Delete the C-IOS1 device from NSO:

1
adapterId: "Local NSO"
2
3
params: {
4
  "path": "/restconf/data/tailf-ncs:devices/device=C-IOS1",
5
  "accept": "application/yang-data+json",
6
  "contentType": "application/yang-data+json",
7
  "method": "DELETE"
8
}
9
10
body: {}

Device lifecycle automation example

A common pattern is to chain restAction calls in a workflow to perform a full device onboarding sequence:

1. Add device — POST to create the device record in NSO
2. Fetch SSH host keys — POST to /restconf/data/tailf-ncs:devices/device=C-IOS1/ssh/fetch-host-keys
3. Sync from device — POST to /restconf/data/tailf-ncs:devices/device=C-IOS1/sync-from
4. Delete device — DELETE to remove the device when decommissioning

Each step uses a separate restAction task in the workflow, chained sequentially.

Service model example

To apply a service model using restAction with commit queue options, include the commit-queue tag in the POST body. Optional parameters such as no-out-of-sync-check and continue-on-error can be included for operational resilience during bulk deployments.

Refer to the Cisco NSO developer documentation for the YANG model paths specific to your service models.

Related reading

• Itential Tools actions
• NETCONF event streams
• Configure the NSO adapter
• Cisco NSO developer documentation