RESTCONF is an IETF standard protocol that gives software a web-style interface to network device data. It uses ordinary HTTPS requests, such as GET to read and PATCH to change, against URLs that map to YANG data models, with data encoded as JSON or XML. It reuses the data model and datastore concepts of NETCONF but presents them the way web developers already work. The standard was published in 2017 and does not expand the name; it combines REST and NETCONF, so we treat it as a name rather than an acronym.
At a glance
- RESTCONF lets software read and change YANG-modeled device data over HTTPS.
- It uses standard HTTP methods (GET, POST, PUT, PATCH, DELETE) and returns standard HTTP status codes.
- Data can be encoded as JSON or XML; the standard requires TLS.
- Each successful edit takes effect when it completes; there is no separate lock or commit step.
- It complements NETCONF rather than replacing it, and many devices support both.
What problem it solves
NETCONF gave network devices a structured, model-driven configuration interface, but it uses SSH sessions and XML remote procedure calls that are unfamiliar to many developers and web-based tools. Meanwhile, most IT automation, ticketing and orchestration platforms already speak HTTP and JSON.
RESTCONF bridges that gap. A developer familiar with web APIs can read an interface’s status or change a VLAN with a familiar request, while the device still validates the change against the same YANG model. That makes it easier to connect network changes to wider IT workflows, such as a service request that provisions a switch port, and to build lightweight tools without specialist network libraries.
How it works
Resources and URLs. Each part of the YANG data tree has a URL under a RESTCONF root on the device. A request to the path for an interface returns that interface’s configuration and, if requested, its state.
Methods. GET reads data, POST creates a new resource or invokes an operation, PUT creates or replaces, PATCH merges changes and DELETE removes. Results come back as standard HTTP status codes and, on error, structured error details.
Encoding. Clients choose JSON or XML through standard HTTP headers. JSON is often preferred by web developers; XML matches NETCONF.
Security. RESTCONF requires HTTPS. Servers present certificates, and clients authenticate with whatever methods the device supports, such as user credentials or client certificates.
Edits and datastores. RESTCONF has no explicit lock or commit operation. Each successful edit applies to the running configuration when it completes, or is committed automatically if the device stages changes in a candidate datastore. If a NETCONF client holds a lock, a RESTCONF edit is rejected until the lock is released.
Events and operations. Devices can expose YANG-defined operations, such as a ping or reboot, and many also offer event notifications as a stream that clients can subscribe to.
When it matters for buyers
- Integrating network and IT tools. If you want ticketing, orchestration or network automation platforms to make network changes directly, an HTTPS interface is often the easiest to connect. See our network as a service page for help comparing providers that expose APIs.
- Small teams. Developers who know web APIs can automate common tasks without learning NETCONF first.
- Vendor claims. “REST API” on a datasheet may mean RESTCONF or a proprietary API. The difference affects portability across vendors.
- Change risk. Without commits or locking, multi-step changes need care in your tooling, such as checks before and after each request.
Questions to ask vendors
- Do your devices support RESTCONF as defined by the IETF, a proprietary REST API, or both?
- Which YANG models are available through RESTCONF, and are they the same as through NETCONF?
- Do you support JSON and XML encoding?
- How are clients authenticated, and can we use certificates or our identity provider?
- How do we roll back a change made through RESTCONF?
- Can we subscribe to event notifications, and in what format?
How it differs from NETCONF
NETCONF and RESTCONF work with the same kind of YANG-modeled data, and a device can support both at once. NETCONF runs over SSH or TLS sessions with XML remote procedure calls and, where devices support them, offers locking, a candidate datastore for staging changes, validation and confirmed commit, which suit coordinated multi-step changes. RESTCONF runs over HTTPS with standard web methods, accepts JSON or XML, and applies each edit as it completes, which suits simple changes and integration with web-based tools. In practice, teams often use NETCONF for bulk or high-risk configuration work and RESTCONF for quick reads, single changes and connections to IT workflow platforms.