Back to BlogNETCONF vs RESTCONF: Rollback or HTTP APIs for Network Engineers

NETCONF vs RESTCONF: Rollback or HTTP APIs for Network Engineers

NTNetverge TeamNetverge editorial teamPublished
restconf protocol featuresrestconf vs netconfnetconf protocol overviewrestconf vs netconf differencesnetconf advantages

NETCONF is the transactional, SSH-based, XML protocol built for device-level, multi-device atomic changes; RESTCONF is the web-friendly, HTTPS and JSON option built for northbound APIs and fast integrations. Choose NETCONF when a change touches multiple devices and needs lock, commit or rollback guarantees. Choose RESTCONF when you are building dashboards, scripts or orchestration layers that favor HTTP tooling and JSON payloads.

TL;DR:

  • For coordinated changes across multiple devices, NETCONF stages edits in a candidate datastore and commits or discards them as one transaction.
  • RESTCONF writes directly to the running configuration without a candidate datastore or built in locks, so applications must guard against conflicting changes.
  • Use RESTCONF for occasional reads, dashboards, or single device scripts; HTTP and JSON tooling avoids maintaining a persistent SSH session.
  • When both protocols access one device, keep coordinated writes on NETCONF and define ownership, because RESTCONF requests can conflict with an open NETCONF candidate session.
  • NETCONF uses SSH, typically on TCP port 830, while RESTCONF requires HTTPS and certificate management, adding a separate maintenance task.

Table of Contents

NETCONF vs RESTCONF: Side-by-Side Technical Comparison

Both protocols configure and retrieve data from network devices using YANG data models, but the mechanics underneath diverge enough to change how you build automation around them.

Dimension NETCONF RESTCONF
Transport & port SSH, typically TCP 830 HTTPS, typically TCP
Encoding XML JSON or XML
Session model Stateful, persistent session Stateless, per-request
Transaction support Lock, candidate datastore, commit and rollback No built-in locking or candidate datastore
Datastore model Running, candidate, startup Running datastore only
Typical use cases Multi-device orchestration, production change workflows Dashboards, northbound APIs, quick scripts

RFC 6241 defines NETCONF as a session-oriented protocol that exchanges XML-encoded RPCs over a reliable transport, with explicit support for running, candidate and startup datastores plus lock, commit and rollback operations. RFC 8040 defines RESTCONF as a stateless HTTP protocol that maps standard verbs onto YANG-modeled resources and supports both JSON and XML, but it implements only a subset of NETCONF's datastore and transaction model.

Three points worth memorizing:

  • NETCONF carries session state and locking; RESTCONF does not, so application-layer safeguards matter more when you build on RESTCONF.
  • RESTCONF speaks the language web developers already know: HTTP verbs, JSON bodies, standard status codes.
  • Both protocols can describe the same YANG-modeled data, so a device that supports both often lets you pick the protocol per task rather than per device.

Technical Differences: Transport, Datastores, Operations, and Encodings

NETCONF runs over SSH, usually as a dedicated subsystem on port 830, as described in RFC 6242 and explained in detail via SNMP — Simple Network Management Protocol | Datacenter Glossary | PODTECH. Every exchange happens inside a persistent session: the client opens the connection, negotiates capabilities, then sends RPCs framed in XML. Operations like get, get-config, edit-config, lock, commit and discard-changes give you fine control over which datastore you touch and when a change becomes permanent. The candidate datastore lets you stage a full set of edits, validate them, then commit as one atomic operation or discard the whole batch if something fails. That staging step is what makes NETCONF the stronger fit for coordinated, multi-device changes where a half-applied configuration is worse than no change at all.

RESTCONF, defined in RFC 8040, drops the session model entirely. Each request is a standalone HTTP call over TLS, and the protocol maps YANG container and list nodes onto URI paths. A GET against a resource path retrieves configuration or state data, a PUT or PATCH modifies it, and a DELETE removes it. There is no candidate datastore and no explicit lock operation: you are working against the running configuration directly, request by request. RESTCONF supports both JSON and XML bodies, with JSON being the more common choice for web and scripting workflows.

NETCONF and RESTCONF technical differences compared

A concrete read comparison makes the contrast clear. In NETCONF, retrieving an interface's configuration means sending a get-config RPC scoped to the running datastore, wrapped in XML, over an open SSH session. In RESTCONF, the equivalent is a single GET request to a URI like /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1, with an Accept: application/yang-data+json header, returning the same underlying YANG-modeled data as JSON.

Both protocols lean on the same modeling language. YANG, standardized in RFC 7950, defines the structure of the data that NETCONF and RESTCONF exchange, and the YANG library concept (originally RFC 7895) lets a client discover which modules a device supports regardless of which protocol it uses to reach them. That shared modeling layer is why the same configuration intent, such as setting an interface description, can be expressed as either an XML edit-config payload or a JSON PATCH body and still mean exactly the same thing to the device.

When to Use NETCONF Versus RESTCONF: Practical Guidance

The right protocol depends less on preference and more on what the task actually requires.

  1. Ask whether the change spans multiple devices and needs to succeed or fail as a unit. If yes, NETCONF's candidate datastore and commit and rollback model gives you that safety net.
  2. Ask who is building the integration. A web or scripting team already fluent in HTTP and JSON will move faster with RESTCONF.
  3. Ask about scale and session overhead. Long-lived NETCONF sessions suit orchestrators managing many devices continuously; stateless RESTCONF calls suit occasional, discrete queries from dashboards or lightweight scripts.
  4. Ask what the payload needs to interoperate with. If downstream systems expect JSON, RESTCONF removes a translation step.

Three scenarios illustrate the split. A change management system pushing a coordinated VLAN update across forty switches benefits from NETCONF because a failed commit rolls back cleanly instead of leaving half the fleet in a new state and half in the old one. A monitoring dashboard polling interface counters every thirty seconds fits RESTCONF better, since each poll is a cheap, independent HTTP call with no need for a held session. A support engineer writing a one-off script to fetch a device's current BGP neighbors will usually reach for RESTCONF first, since curl and JSON get them an answer faster than standing up an SSH-based RPC client.

Pro Tip: When a task could go either way, default to NETCONF for anything that writes configuration to more than one device, and default to RESTCONF for anything that only reads or writes to a single device.

Tooling, Libraries, and Quick Examples

Getting hands-on with either protocol takes only a few common tools.

  • For NETCONF, the ncclient Python library wraps session setup, capability exchange and RPC framing, so a get-config call becomes a few lines of Python instead of raw XML over SSH.
  • Ansible ships NETCONF-aware modules that let you express edit-config style changes in a playbook instead of hand-building XML payloads.
  • For RESTCONF, curl or Postman against a URI such as /restconf/data/ietf-interfaces:interfaces with a JSON Accept header is often the fastest way to confirm a device's YANG paths before writing any code.
  • Python's requests or httpx libraries handle RESTCONF the same way they handle any HTTPS API: set the headers, send the verb, parse the JSON response.

In practice, orchestrators and infrastructure-as-code pipelines tend to hold NETCONF sessions open for coordinated device-level work, while dashboards and northbound integrations call RESTCONF endpoints on demand. That split shows up naturally once a platform needs to both drive configuration changes and surface live state to a web interface.

Security and Deployment Considerations

NETCONF's dependence on SSH means the usual SSH hardening rules apply: manage port 830 access through firewall rules, route sessions through a bastion host where possible, and tie accounts to role-based credentials rather than shared logins. Vendor documentation notes that enabling NETCONF generally requires only the device's SSH subsystem, which keeps the exposed surface relatively small.

RESTCONF depends on the device running an HTTP(S) stack, which brings TLS certificate lifecycle management into the picture: certificates need issuance, renewal and revocation, and any proxy or load balancer sitting in front of the device adds another layer to monitor and secure. Vendor guides on YANG and protocol support confirm that RESTCONF's HTTP dependency is a separate operational commitment from NETCONF's SSH-only footprint.

Limit exposure on both fronts: restrict management-plane access to known jump hosts, rotate credentials and certificates on a schedule, and log every session or request against an inventory of who should be touching which device.

Security and Deployment Considerations — overview diagram

Coexistence, Migration, and Integration Patterns

Many devices expose NETCONF and RESTCONF at the same time, which makes phased adoption straightforward rather than an all-or-nothing switch. A common pattern is to keep NETCONF as the transactional backbone for orchestrator-driven, multi-device changes while exposing RESTCONF northbound for dashboards, ticketing systems and quick integrations that only need to read or write a single device's state.

The risk to watch for is a transactional gap: if one system writes through RESTCONF's stateless, un-locked path while another holds a NETCONF candidate session open against the same device, the two can step on each other. Keep write paths for coordinated changes on NETCONF, keep RESTCONF scoped to reads and single-device writes, and document which systems own which path so the boundary stays clear as your network automation footprint grows.

Why Protocol Choice Shapes Your Observability Strategy

NETCONF and RESTCONF are not competitors so much as two doors into the same YANG-modeled data, and a platform that only speaks one of them leaves half the network's configuration and state data harder to reach. Monitoring approaches should take in data regardless of which path produced it, correlate it against the rest of a network's telemetry, and feed it into AI agents that drive anomaly detection and automated remediation. A device-level commit pushed through NETCONF and a status check pulled through RESTCONF both end up describing the same underlying state, and treating them as interchangeable inputs is what keeps a knowledge graph accurate.

— Jim

FAQ

What is the difference between RESTCONF and a REST API?

RESTCONF is a specific, standardized protocol defined by RFC 8040 that maps YANG data models onto HTTP resources using a fixed URI structure. A generic REST API follows REST principles but has no required data modeling language or standardized resource layout, so two REST APIs can differ completely in structure while two RESTCONF implementations stay consistent because they both derive their paths from YANG.

What is the difference between NETCONF and YANG?

NETCONF is the transport and operations protocol, defined in RFC 6241, that carries configuration and state data between a client and a device. YANG, defined in RFC 7950, is the modeling language that describes the structure of that data, and NETCONF relies on YANG models to know what it is reading or writing.

Which two protocols can use YANG models?

NETCONF and RESTCONF both use YANG models to define the structure of the configuration and state data they exchange. This shared foundation is why the same YANG module can be served over either protocol without changing its underlying data structure.

What is port 830 used for?

Port 830 is the IANA-assigned TCP port for NETCONF sessions running over SSH, as described in the RFC covering NETCONF over SSH. Using a dedicated port makes it simpler to identify and firewall NETCONF traffic separately from general SSH access.

Should I pick NETCONF or RESTCONF for a new automation project?

Pick NETCONF when your project needs atomic, multi-device changes with rollback safety, and pick RESTCONF when you need a web-friendly API for dashboards or quick scripts. Many devices expose both, so the choice can be made per task rather than locked in for the whole project, and platforms like our monitoring tools can consume data from either path.

Sources

Recommended