REST vs NETCONF vs RESTCONF and YANG

The rule: YANG is the model, NETCONF and RESTCONF are two ways to reach it

A plain REST API is whatever a vendor decided to publish: its own URLs, its own JSON fields, usually on a controller. NETCONF (RFC 6241) and RESTCONF (RFC 8040) are standard protocols that configure a device from a YANG data model instead of CLI text. NETCONF speaks XML remote procedure calls over SSH; RESTCONF maps the same YANG data onto HTTPS methods with JSON or XML bodies. The decision rule for exam questions: if the question says XML over SSH, port 830, or candidate datastore and commit, the answer is NETCONF; if it says HTTP methods, URLs and JSON against a YANG-modelled device, it is RESTCONF; if it says a controller or cloud service with its own documented endpoints, it is a REST API.

One change, three interfaces

The task: set the description of interface GigabitEthernet1 on an IOS XE router to uplink. The data lives in the standard ietf-interfaces YANG module.

NETCONF sends an XML <rpc> over an SSH session. This one writes to the running datastore, which needs the device to advertise the writable-running capability (many devices want the candidate datastore plus a <commit> instead):

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>GigabitEthernet1</name>
          <description>uplink</description>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

The reply is <rpc-reply> containing <ok/>.

RESTCONF expresses the same thing as an HTTP request. PATCH merges, so only the description changes:

PATCH https://r1.example.net/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
Content-Type: application/yang-data+json

{ "ietf-interfaces:interface": [ { "name": "GigabitEthernet1", "description": "uplink" } ] }

A successful plain patch returns 204 No Content when there is no response body (200 OK when there is one). The list key (interface=GigabitEthernet1) is in the URL and must match the body. In JSON a list entry is written as an array, even when the URL selects a single entry, which is how the RFC 8040 examples encode it.

A vendor REST API, for example a controller, would use whatever path its documentation defines, such as PUT /api/v1/devices/{id}/interfaces/{name} with its own JSON. Nothing about it is standardised, so there is no YANG and no capability negotiation. See REST API basics for the HTTP side.

What YANG actually describes

YANG (RFC 7950) is a modelling language, not a protocol and not a data format. A module is built from a few node types:

Nodes marked config false are operational state (counters, status) and can be read but not written. Because every vendor can implement the same standard module, a script written against ietf-interfaces works across devices that support it; native vendor modules (Cisco publishes its IOS XE models on GitHub) cover features the standard modules do not. This is the reason model-driven programmability exists: structured data in, structured data out, no screen scraping. How the structured data is written (JSON, XML) is covered in JSON vs YAML vs XML.

The three side by side

Two RESTCONF details are testable. The POST method creates a child resource inside the target and returns 201 Created with a Location header; PUT creates or replaces the target resource itself, returning 201 if new and 204 if it replaced something. And a RESTCONF client finds the root by fetching /.well-known/host-meta, though on IOS XE the root is normally /restconf.

Which exams test this

The comparison is a 200-901 topic. A CCNA v1.1 candidate needs only the REST row of the table, and a CCNA v2.0 candidate none of it.

How questions are built around it

The usual trap is mixing up the transport and the encoding. Constraint words that decide the answer:

• “XML” plus “SSH” or “830”: NETCONF. RESTCONF never uses SSH, and NETCONF never uses JSON.
• “HTTP verbs” plus “YANG”: RESTCONF, not a plain REST API.
• “Candidate”, “lock”, “commit”, “roll back”: NETCONF’s transactional model.
• “Screen scraping”, “CLI parsing”: the problem all three model-driven options replace.
• “Defines the structure of configuration data”: YANG, not NETCONF. A distractor often offers YANG as a protocol.
• “Controller”, “dashboard API” with named endpoints: REST, not RESTCONF.

Reply questions give you a fragment and ask which interface produced it. Namespaces (xmlns="urn:ietf:params:xml:ns:...") and <rpc-reply> mean NETCONF; a JSON key like ietf-interfaces:interface (module name, colon, node) means RESTCONF.

Practice questions

Go deeper

• RFC 8040, RESTCONF Protocol
• RFC 6241, NETCONF and RFC 7950, YANG 1.1
• Cisco IOS XE Programmability Guide, RESTCONF Protocol
• Next on this site: REST API basics, Python for network engineers, Ansible vs Terraform and the 200-901 APIs guide.