RESTCONF
RESTCONF carries the same YANG models over ordinary HTTP, using the encoding defined in RFC 8040. Switch the protocol toggle in the request panel and the selection you have already built is re-rendered as an HTTP method, a URL, and a JSON body.
The device needs restconf configured and the HTTPS
server running — RESTCONF will not start over plain HTTP. See
preparing the device.
If the device also has ip http server enabled, the
plain HTTP port stays open and answers requests, but it returns
404 Not Found for every RESTCONF URL. The web server is
running; the RESTCONF endpoint is simply not attached to it. A 404
over http:// for a URL that works over
https:// is almost always this rather than a wrong
path.
How a path becomes a URL
Three rules account for almost all of it.
- The first node is qualified by its module —
ietf-interfaces:interfaces - Later nodes are bare, unless an augment changes module, which re-qualifies them
- A list entry carries its keys in the path —
interface=GigabitEthernet1
# the YANG path /if:interfaces/if:interface/if:description # the same node, addressed over RESTCONF GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1/description
Keys are percent-encoded. This matters immediately on Cisco
kit — Gi0/0/1 becomes Gi0%2F0%2F1, because an
unescaped slash would look like another path segment.
One resource per request
This is the substantive difference between the two protocols. A
NETCONF filter can ask for several unrelated branches in one message,
whereas a RESTCONF call addresses exactly one resource. Where several of
your selected leaves share a parent, they are folded into a single
request using a fields query:
GET /restconf/data/ietf-interfaces:interfaces/interface?fields=name;description;type
Anything that cannot be folded in becomes a request of its own, and the panel tells you when that happens rather than quietly issuing extra calls. Each planned request lists the tree paths it covers, so you can see exactly which of your selections it accounts for.
Writing
The NETCONF edit operations have direct HTTP equivalents, so the same selection can be written either way. In the request body, the member is named with the module that defines it:
| NETCONF | RESTCONF | Means |
|---|---|---|
merge | PATCH | Merge into the resource |
replace | PUT | Create or replace it |
create | POST | Create a child |
delete / remove | DELETE | Remove it |
PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1/description
Content-Type: application/yang-data+json
{
"ietf-interfaces:description": "uplink"
}
There is no candidate datastore. RFC 8040 has no staging area and no commit — a write lands immediately on the running configuration. If you want to stage a change, validate it, and apply it as one transaction, that is NETCONF.
Checking a device supports it
Unlike NETCONF, RESTCONF has no handshake that announces itself, so
if you do not ask, the first sign that it is unavailable is a request
failing. The Check RESTCONF button on the Devices page asks the
device directly and reports its root path along with the optional
capabilities it supports. The one to look for is fields,
since that is what makes the request folding described above legal.
Where the two differ
| NETCONF | RESTCONF | |
|---|---|---|
| Transport | SSH, port 830 | HTTPS, port 443 |
| Encoding | XML | JSON or XML |
| Per request | Several branches in one filter | One resource |
| Staging | candidate + commit | None — writes are immediate |
| Transactions | Yes, with confirmed-commit | No |