NETCONF and RESTCONF give network software structured ways to read and change device data without scraping command-line output. On Cisco IOS XE, both interfaces are tied to YANG data models, so the automation can address defined configuration and operational objects rather than relying on the exact wording of a CLI display. That shared modeling layer is the most important idea: NETCONF and RESTCONF are different protocols for working with model-driven data, not competing replacements for YANG.
The current CCNA Automation 200-901 v1.1 blueprint includes APIs and model-driven programmability. Engineers moving beyond basic REST calls need to understand what NETCONF and RESTCONF have in common, where their operational behavior differs, and why a device’s supported YANG modules matter more than memorizing one request example.
Start with the YANG model, not the transport protocol
YANG defines the schema of configuration and operational data. A module can describe containers, lists, leaf values, data types, constraints, RPCs, and notifications. NETCONF and RESTCONF expose that modeled information through different request mechanisms, but neither protocol invents the underlying hierarchy. If a model contains an interface list keyed by interface name, both protocols ultimately need to address that same modeled structure.
This is why the native, IETF, OpenConfig, and Cisco YANG models matters. A device may support IETF standards-based modules, OpenConfig modules, Cisco native modules, or a combination. The exact modules and revisions vary by software release and platform. Before writing production automation, discover what the target actually advertises and build requests against that support rather than assuming that a model found in a repository exists on every Cisco device.
Model awareness also improves portability. A client that separates business intent from model-specific paths can support more than one device family by mapping the same high-level task to different YANG trees. The protocol is only one layer of that abstraction. A RESTCONF client using the wrong model is no more portable than a NETCONF client using the wrong model.
NETCONF uses RPC messages over a persistent management session
NETCONF is an XML-based protocol designed for network configuration management. A client establishes a secure session, commonly over SSH, exchanges capabilities, and sends RPC requests such as <get>, <get-config>, or <edit-config>. The server replies with an <rpc-reply> that contains data or structured error information.
The session-oriented model is useful when a workflow performs several related operations. The client can learn server capabilities at session establishment, issue multiple RPCs, and use NETCONF functions that are specifically designed around configuration datastores. Depending on server capabilities, workflows may have access to operations and datastore behaviors that are richer than a simple sequence of independent HTTP requests.
Do not assume that every NETCONF capability is universally available. Features such as candidate configuration, confirmed commit, writable-running, validation, or specific filtering behavior depend on what the server advertises. Robust clients inspect capabilities and treat optional behavior as optional. The safest automation asks the device what it supports instead of encoding an idealized NETCONF feature list.
RESTCONF maps YANG data to HTTPS resources and methods
RESTCONF exposes YANG-defined data through an HTTP-based interface. A client uses resource paths plus methods such as GET, POST, PUT, PATCH, and DELETE as supported by the target operation. Payloads can be encoded in JSON or XML according to the RESTCONF rules. This feels familiar to developers who already work with web APIs because authentication, headers, status codes, URLs, and request bodies fit common HTTP tooling.
Cisco IOS XE documentation describes RESTCONF as a REST-like API over YANG-modeled configuration, state, RPC operations, and events. The convenience of HTTP does not make the data unstructured. Resource paths are derived from YANG modules and nodes, namespaces still matter, and the client must send a body that matches the schema.
RESTCONF’s stateless request model can be convenient for lightweight scripts, web services, and systems that already have strong HTTP client libraries. It also fits naturally with API gateways, request tracing, TLS tooling, and common observability practices. Those advantages are operational rather than proof that RESTCONF is inherently better than NETCONF for every change.
Compare read operations by thinking about the data you need
Both protocols can retrieve modeled state, but they express the request differently. A NETCONF client might use <get> with a subtree or XPath filter. A RESTCONF client issues a GET to the appropriate data resource and may use supported query parameters. In either case, the goal is to retrieve the smallest useful dataset and parse it according to the model.
Filtering matters at scale. Pulling the entire configuration from hundreds of devices to answer one interface question wastes bandwidth and increases parsing work. A well-designed workflow identifies the specific list, key, or subtree it needs. That makes the automation faster and reduces the chance of accidentally depending on unrelated fields.
The response format changes the client code. NETCONF responses are XML, so namespace-aware XML parsing is essential. RESTCONF frequently uses JSON because it maps conveniently to Python dictionaries and lists, although XML can also be used. The YANG, NETCONF, and RESTCONF is easier to understand when the engineer separates the modeled data from its wire encoding.
Compare writes by examining transaction and datastore needs
Configuration changes are where protocol selection becomes more consequential. NETCONF was designed around network configuration datastores and RPC operations. An <edit-config> request can target the datastore supported by the server and apply structured configuration. Additional capabilities may support validation, locking, candidate workflows, or confirmed commits. These features can be valuable when several edits must be treated as a coordinated change.
RESTCONF uses HTTP methods against modeled resources. A client can create, replace, modify, or delete data according to the method, resource, schema, and implementation support. This can be straightforward for resource-oriented changes, especially when the automation platform already uses HTTP everywhere else.
Neither interface removes the need to understand device semantics. Two individually valid edits can still produce a bad network design. Before a write, retrieve current state, validate prerequisites, build the intended change, and confirm the target set. After the write, read the relevant state again and verify the operational result. A successful protocol response proves that the server processed a request; it does not prove that end-to-end connectivity or policy intent is correct.
NETCONF capabilities make feature discovery explicit
NETCONF begins with a capability exchange that tells the client which protocol features and model-related capabilities the server exposes. Modern YANG workflows also use the YANG library to discover supported modules and revisions. This encourages capability-driven code: the client can branch based on actual server support instead of relying on a hard-coded platform assumption.
Capability discovery is particularly important for mixed fleets. Even devices running the same broad operating-system family may differ in release, license, or feature support. A network automation system should maintain a compatibility view and fail clearly when a required model or capability is absent. Silently falling back to a different configuration method can make change behavior unpredictable.
The same discipline applies to RESTCONF even though the initial interaction looks like a conventional web API. Query the supported YANG library, test the specific resource, and honor documented media types and methods. RESTCONF clients should not infer support merely because the HTTPS endpoint responds.
Authentication and transport security are separate from the data model
NETCONF is commonly carried over SSH, while RESTCONF is commonly exposed over HTTPS. These transports provide encrypted channels and connect the API request to a device identity and an authenticated user or service account. The authorization policy then determines what the identity is allowed to read or change.
A secure implementation validates host keys or certificates, protects credentials, uses least privilege, and logs enough context to trace changes. Disabling certificate verification in a RESTCONF script or automatically trusting every SSH host key may make a lab exercise work, but it weakens protection against impersonation in production.
AAA design matters as much as client code. Dedicated automation identities should have only the permissions required by the workflow, and high-impact write access should be separated from read-only monitoring where practical. Credentials should come from a protected runtime source rather than the repository that contains the automation.
Error handling differs in form but should lead to the same discipline
NETCONF returns structured RPC errors that can identify the type, tag, severity, path, and message associated with a failure. RESTCONF combines HTTP status codes with structured error bodies. A client should preserve that information and translate it into an actionable operational message rather than collapsing every failure into “request failed.”
Errors should be classified before retrying. Authentication failures, schema violations, unsupported operations, invalid values, and missing resources usually require a correction rather than repeated attempts. Temporary transport failures or selected server-side conditions may justify bounded retries with backoff. For write operations, verify current state before a retry so an ambiguous response does not produce an unintended duplicate action.
Logging should identify the device, model path or resource, operation, and correlation context without recording passwords or sensitive payloads. This creates a troubleshooting trail that can be joined with device logs and change records when a model-driven workflow behaves unexpectedly.
Choose the protocol from workflow requirements, then test the exact platform
RESTCONF is attractive when a team wants a familiar HTTPS/JSON interaction, easy integration with web tooling, and resource-oriented operations. NETCONF is attractive when a workflow benefits from a persistent session, explicit capabilities, XML-based RPCs, or datastore-oriented configuration functions. The choice should come from the required behavior and supported platform, not from a rule that one protocol is modern and the other is obsolete.
The current 300-435 ENAUTO exam path goes deeper into enterprise automation, including model-driven interfaces and operational automation. At that level, engineers should be comfortable reading both types of requests, discovering models, validating server support, and troubleshooting schema or transport problems.
A useful design is to isolate protocol-specific code behind a common service layer. The application can express intent such as “retrieve interface state” or “apply this routing policy,” while adapters handle NETCONF XML or RESTCONF HTTP details. Tests can then verify the same high-level intent against different adapters. That does not make protocols interchangeable, but it prevents the rest of the application from being tightly coupled to one wire format.
Most importantly, test against the exact Cisco platform and software release that will receive the change. Model support, RPC behavior, query options, and implementation details evolve. Model-driven automation is safer than screen scraping only when the client respects the model and the server’s real capabilities. The protocol is part of the design; the supported data model and validation workflow are what make the automation dependable.
Performance can also influence the choice. A persistent NETCONF session can reduce repeated connection setup for a sequence of operations, while HTTP connection pooling gives RESTCONF clients similar transport efficiency without changing RESTCONF’s request semantics. Measure the real controller and device behavior before optimizing. A poorly scoped request that retrieves thousands of modeled nodes will dominate runtime regardless of protocol.
Payload construction should be schema-driven in both cases. For NETCONF, build XML with a namespace-aware library rather than concatenating strings that can produce malformed or ambiguous elements. For RESTCONF, serialize dictionaries or typed objects into JSON and let the HTTP client set the documented media type. Escaping, encoding, and namespaces are software problems best handled by libraries rather than hand-built text.
Finally, establish a compatibility test for every supported device release. The test can connect, discover modules, read a harmless object, perform a controlled lab write, and validate the result through both the intended protocol and device state. This catches model revision changes, access-control differences, or implementation regressions before a production upgrade changes the behavior of hundreds of automation jobs.
Protocol selection can be made per workflow rather than per organization. A telemetry or inventory service may use RESTCONF because its HTTP tooling is mature, while a configuration transaction on the same IOS XE platform may use NETCONF because the required datastore capability is available there. Supporting both is reasonable when the team has a common YANG understanding and clear adapters. The dangerous design is not using two protocols; it is having two unrelated code paths that interpret network intent differently.
Documentation should record the exact model path and protocol assumptions for each automation feature. Include the module, revision where relevant, key nodes, expected content type or namespace, and tested software versions. When the platform is upgraded, that record becomes a targeted regression checklist instead of forcing the team to rediscover how a working request was constructed. It also helps reviewers distinguish a deliberate model path from a copied string that nobody understands.
Be careful with configuration replace versus merge semantics. A request that looks like a small update can replace a larger modeled resource if the selected operation and target path are wrong. Read the protocol and platform behavior for PUT, PATCH, <edit-config>, and operation attributes before using them in production. Test with neighboring configuration present so the lab proves that unrelated nodes survive exactly as intended.
Change windows should also preserve the raw request and sanitized response as artifacts. When a model-driven deployment fails later validation, these records show what the automation actually asked the device to do, which model path it targeted, and what the server returned. That evidence is far more useful than a log line saying only that “RESTCONF succeeded.”