skip to content

How does RESTCONF differ from NETCONF in transport, message encoding and the way a client converses with a device?

level: juniorimportance: must knowfreq 24%

answer

  1. two front doors, one YANG model
  2. HTTPS versus an SSH subsystem
  3. XML only versus XML or JSON
  4. one request versus a long-lived session

basics

~20 s

RESTCONF carries YANG-modelled data over HTTPS as XML or JSON, one self-contained HTTP request per operation. NETCONF sends XML RPCs over a long-lived SSH or TLS session, which can hold locks and stage edits before committing them.

solid answer

~40 s

Both protocols manage the same YANG-modelled configuration and state data, and RESTCONF reuses NETCONF's datastore concepts. RESTCONF (RFC 8040) runs over HTTP and must use TLS; it maps YANG nodes to URLs, edits them with `POST`, `PUT`, `PATCH` and `DELETE`, reads them with `GET`, and accepts `application/yang-data+xml` or `application/yang-data+json`. NETCONF (RFC 6241) must support SSH, where it runs as the `netconf` subsystem on port 830, and exchanges XML `<rpc>` and `<rpc-reply>` messages. NETCONF is connection-oriented: the session persists between operations, which is what lets it hold a `<lock>`, build a change in the candidate datastore and `<commit>` it. RESTCONF drops explicit locking and each HTTP request stands alone. RESTCONF is easier for web tooling to consume; NETCONF is stronger when several edits must land together.

go deeper

for a junior

Recall the three axes: HTTPS versus SSH, XML or JSON versus XML only, and a single HTTP request versus a long-lived session. Both protocols manage the same YANG data.

for a middle

Explain why the session matters: NETCONF's persistent connection lets it hold a lock and commit staged edits, while stateless HTTP leaves RESTCONF without locks or a client-controlled commit.

for a senior

Connect the transport choice to operations: certificate or HTTP-scheme authentication for RESTCONF, SSH accounts or mutual TLS for NETCONF, and the same access-control rules applied to both on one device.

for a principal

Frame the comparison as a fit to workflows: per-request edits from web tooling versus staged, locked, committed changes, and say when running both against one datastore needs coordination.

## Same data, two front doors NETCONF and RESTCONF are both **management protocols for YANG-modelled data**: the configuration a device accepts and the state it reports, described by YANG modules (RFC 7950). They are not rival data models. A device that implements an interface module exposes the same leaves to both protocols, and RFC 8040 says RESTCONF provides CRUD operations "on a conceptual datastore containing YANG-defined data, which is compatible with a server that implements NETCONF datastores". Section 1.4 of RFC 8040 shows the two servers co-located on one device, editing one datastore. The differences are in how a client reaches that data and how long the conversation lasts. ## Transport and authentication | | NETCONF (RFC 6241) | RESTCONF (RFC 8040) | |---|---|---| | Mandatory transport | SSH (RFC 6242), as the `netconf` subsystem | HTTP over TLS; the `https` scheme MUST be supported | | Default port | 830 for SSH; 6513 for the TLS mapping of RFC 7589 | 443, the `https` default | | Server identity | SSH host key, or an X.509 certificate under RFC 7589 | X.509v3 certificate, validated by path or by pinning | | Client identity | SSH user authentication, or mutual X.509 under RFC 7589 | TLS client certificate (SHOULD); an HTTP authentication scheme (MAY) | | Messages | XML `<rpc>` / `<rpc-reply>` | HTTP methods on resource URLs | | Encodings | XML | XML or JSON | Two points interviewers like to probe: - **RESTCONF never runs over plain HTTP.** RFC 8040 §2.1: a server MUST support TLS, and RESTCONF "MUST NOT be used over HTTP without using the TLS protocol". - **NETCONF is not SSH-only.** SSH is the mandatory-to-implement mapping (RFC 6241 §2.3), but RFC 7589 defines NETCONF over TLS with mutual X.509 authentication on port 6513. Authorisation is shared. The NETCONF Access Control Model, now RFC 8341 (which obsoletes RFC 6536, the version RFC 8040 cites), is written for both protocols, and RFC 8040 maps each HTTP method to the equivalent NETCONF operation so the same rules apply. ## Encoding NETCONF messages are XML from top to bottom: the `<rpc>` envelope, the operation, and the data. RESTCONF carries the data itself in one of two media types: - `application/yang-data+xml` — the same XML encoding NETCONF uses for the data; - `application/yang-data+json` — the JSON encoding of YANG defined in RFC 7951, with module-qualified member names. JSON is a large part of RESTCONF's appeal: a web application can build and parse bodies with the tools it already has. ## Session model: connection versus request This is the difference that matters most for workflows. 1. **NETCONF is connection-oriented.** RFC 6241 §2.1: "NETCONF is connection-oriented, requiring a persistent connection between peers... NETCONF connections are long-lived, persisting between protocol operations." Resources a session acquires, such as a lock, last until they are released or the session closes. 2. **RESTCONF rides on HTTP, which RFC 9110 §3.3 defines as stateless**: each request's meaning can be understood in isolation, whatever connection it arrives on. RFC 8040 §1.2 says RESTCONF implements "a subset of the interaction capabilities provided by the NETCONF protocol — for instance, by eliminating datastores and explicit locking": the client edits one conceptual datastore, picks no datastore and takes no lock. 3. **Consequence:** a RESTCONF client has nothing to hang a lock on. RFC 8040 §1.4 states it plainly: "RESTCONF cannot manipulate locks." ## What the session buys NETCONF Because the conversation persists, a NETCONF client can run a multi-step change: - `<lock>` the datastores so no other session, and no CLI or SNMP writer, can change them; - send several `<edit-config>` operations into the **candidate** datastore, a scratch copy; - `<validate>` the result, then `<commit>` it to running in one step — if the device cannot apply all of it, running stays unchanged; - optionally use a **confirmed commit**, which reverts unless confirmed within a timeout. RESTCONF has none of these as client-visible steps. RFC 8040 §3.4 says "configuration edit transaction management and configuration persistence are handled by the server and not controlled by the client". Each request is its own unit of change; for collisions RESTCONF offers optimistic checks with entity-tags and timestamps rather than locks. ## How to frame the choice Neither protocol is simply better: - RESTCONF suits small, independent changes and reads from web applications, portals and scripts: any HTTP stack, JSON bodies, familiar authentication. - NETCONF suits changes that must be staged, held under a lock and committed together, and long-lived automation sessions. - Many devices offer both against the same datastores, so the choice can be per workflow rather than per network.

  • Does RESTCONF's use of HTTPS make NETCONF the less secure protocol?
    No. Both require an authenticated, encrypted transport: NETCONF over SSH, or over TLS with mutual X.509 under RFC 7589; RESTCONF over TLS with a server certificate and client authentication by certificate or an HTTP scheme. Both apply the NETCONF Access Control Model (RFC 8341) to authorise operations. The difference is the identity plumbing and tooling each fits into, not the strength of protection.
  • Can one device serve both protocols against the same configuration?
    Yes. RFC 8040 §1.4 describes a RESTCONF server co-located with a NETCONF server. RESTCONF edits go to running if the device advertises `:writable-running`; otherwise they go to the candidate and are committed immediately. A NETCONF lock on the datastore an edit would modify makes the RESTCONF edit fail with `409 Conflict`.

saying these in an interview costs you the question

  • RESTCONF uses its own data models, separate from NETCONF's YANG modules.
  • RESTCONF may run over plain HTTP inside a trusted management network.
  • NETCONF can only ever run over SSH; there is no TLS mapping.
  • NETCONF will answer in JSON if the client asks for it.
  • A RESTCONF client keeps a session open, so it can lock a datastore like NETCONF.