RESTCONF

RESTful API interface for IOS-XE device configuration and operational state retrieval.

Enable RESTCONF on IOS-XE

Prerequisites — HTTPS and RESTCONF
Switch(config)# ip http secure-server
Switch(config)# ip http authentication local
Switch(config)# restconf

RESTCONF runs over HTTPS (port 443). Unlike NETCONF (SSH on 830), it uses standard HTTP methods: GET, PUT, POST, PATCH, DELETE.

Verify RESTCONF is running
Switch# show running-config | section restconf
Switch# show platform software yang-management process

YANG-to-URL Mapping

RESTCONF URLs map directly to YANG model paths:

https://<host>/restconf/data/<module>:<container>/<node>

Example:
https://10.50.1.10/restconf/data/ietf-interfaces:interfaces
https://10.50.1.10/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
https://10.50.1.10/restconf/data/Cisco-IOS-XE-native:native/hostname

List keys use = syntax: interface=GigabitEthernet1 selects one interface by its key.

Content-Type Headers

Format Header

JSON

application/yang-data+json

XML

application/yang-data+xml

Both Content-Type (request body) and Accept (response format) must be set. JSON is more readable; XML matches NETCONF payloads for consistency.

GET — Read Configuration

Retrieve all interfaces — JSON
curl -s -k -u admin:<PASSWORD> \
  -H "Accept: application/yang-data+json" \
  https://10.50.1.10/restconf/data/ietf-interfaces:interfaces \
  | jq '.'
Retrieve a specific interface
curl -s -k -u admin:<PASSWORD> \
  -H "Accept: application/yang-data+json" \
  "https://10.50.1.10/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1" \
  | jq '.'

Expected response:

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet1",
    "description": "Uplink to Core",
    "type": "iana-if-type:ethernetCsmacd",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "10.50.1.10",
          "netmask": "255.255.255.0"
        }
      ]
    }
  }
}

PATCH — Modify Configuration

Update an interface description — PATCH merges, does not replace
curl -s -k -u admin:<PASSWORD> \
  -X PATCH \
  -H "Content-Type: application/yang-data+json" \
  -H "Accept: application/yang-data+json" \
  "https://10.50.1.10/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1" \
  -d '{
    "ietf-interfaces:interface": {
      "name": "GigabitEthernet1",
      "description": "Updated via RESTCONF"
    }
  }'

HTTP 204 (No Content) means success. PATCH is idempotent and non-destructive — it only changes the fields you specify.

PUT — Replace Configuration

Replace entire interface config — PUT overwrites, omitted fields revert to defaults
curl -s -k -u admin:<PASSWORD> \
  -X PUT \
  -H "Content-Type: application/yang-data+json" \
  -H "Accept: application/yang-data+json" \
  "https://10.50.1.10/restconf/data/ietf-interfaces:interfaces/interface=Loopback0" \
  -d '{
    "ietf-interfaces:interface": {
      "name": "Loopback0",
      "type": "iana-if-type:softwareLoopback",
      "enabled": true,
      "ietf-ip:ipv4": {
        "address": [
          {
            "ip": "10.50.255.1",
            "netmask": "255.255.255.255"
          }
        ]
      }
    }
  }'
PUT replaces the entire resource. If you omit the IP address, it gets removed. Use PATCH for partial updates.

POST — Create New Resources

Create a new Loopback interface
curl -s -k -u admin:<PASSWORD> \
  -X POST \
  -H "Content-Type: application/yang-data+json" \
  -H "Accept: application/yang-data+json" \
  "https://10.50.1.10/restconf/data/ietf-interfaces:interfaces" \
  -d '{
    "ietf-interfaces:interface": {
      "name": "Loopback99",
      "type": "iana-if-type:softwareLoopback",
      "enabled": true
    }
  }'

HTTP 201 (Created) means success. HTTP 409 (Conflict) means the resource already exists — use PUT or PATCH instead.

DELETE — Remove Configuration

Delete a Loopback interface
curl -s -k -u admin:<PASSWORD> \
  -X DELETE \
  "https://10.50.1.10/restconf/data/ietf-interfaces:interfaces/interface=Loopback99"

Operational Data

Read operational state — use /restconf/data with the -oper models
curl -s -k -u admin:<PASSWORD> \
  -H "Accept: application/yang-data+json" \
  "https://10.50.1.10/restconf/data/Cisco-IOS-XE-interfaces-oper:interfaces/interface=GigabitEthernet1" \
  | jq '.["Cisco-IOS-XE-interfaces-oper:interface"]'

This returns counters, oper-status, speed, and statistics — the equivalent of show interface GigabitEthernet1.

Common Endpoints

Endpoint Description

/restconf/data/ietf-interfaces:interfaces

All interfaces (config)

/restconf/data/Cisco-IOS-XE-native:native

Full native IOS-XE config tree

/restconf/data/Cisco-IOS-XE-native:native/hostname

Device hostname

/restconf/data/Cisco-IOS-XE-native:native/ip/route

Static routes

/restconf/data/openconfig-interfaces:interfaces

Interfaces via OpenConfig model

/restconf/data/Cisco-IOS-XE-interfaces-oper:interfaces

Interface operational data

/restconf/operations

Available RPC operations

/.well-known/host-meta

RESTCONF root discovery

Discovery

Find the RESTCONF root URL — per RFC 8040
curl -s -k -u admin:<PASSWORD> \
  https://10.50.1.10/.well-known/host-meta \
  | grep restconf

Expected output:

<Link rel="restconf" href="/restconf"/>

HTTP Methods Summary

Method Action Idempotent?

GET

Read config or operational data

Yes

POST

Create a new resource

No (409 if exists)

PUT

Create or replace entire resource

Yes

PATCH

Merge partial update into resource

Yes

DELETE

Remove a resource

Yes

For automation scripts, prefer PATCH over PUT. PATCH is safer because it only touches what you specify — no risk of accidentally wiping fields you forgot to include.