3.3Device APIs and model-driven programmability

Traditional network operations meant a human typing show/configure at the CLI, but model-driven programmability is a world of reading/writing device configuration and state as structured data. The confusing part is the relationship among YANG, NETCONF, and RESTCONF. They play different roles, so lumping them as "all model-driven" leads to misreading responses and mis-selecting methods. This section organizes the three as "the model (YANG)," "the XML/SSH protocol (NETCONF)," and "the HTTP protocol (RESTCONF)," and adds the DevNet resources for trying things without physical hardware.

3.3.1On-box APIs (IOS XE / NX-OS)

• On IOS XE, enabling netconf-yang/restconf makes the device itself serve NETCONF (TCP 830) and RESTCONF (HTTPS 443) endpoints, so external scripts can handle configuration/state in a model-driven way. A programmable entry point independent of the CLI opens on the device.
• NX-OS (Nexus) likewise supports NETCONF/RESTCONF and additionally offers on-box automation (running Python/Bash directly on the switch) and NX-API. The point is that "recent Cisco devices can read/write configuration as structured data," so you need not rely on scraping hand-typed CLI.

3.3.2The three pillars: YANG / NETCONF / RESTCONF

• YANG is a language for defining data models. It expresses the hierarchy of configuration/state with container/list/leaf (e.g., a list of interfaces containing leafs like name and enabled). YANG itself is not a protocol but a type definition of what data (with what structure) is handled, and both NETCONF and RESTCONF share the same YANG model.
• NETCONF is a protocol exchanging XML over SSH (TCP 830). It has the concept of datastores, so you can apply changes to candidate (an editable draft) and commit them to running, which suits transactional configuration changes (rollback on partial failure). Operations include <get>/<edit-config>.
• RESTCONF follows REST conventions over HTTP(S) and handles JSON or XML. CRUD maps to HTTP methods (read = GET / create = POST / replace = PUT / partial update = PATCH / delete = DELETE). The URL expresses YANG's resource hierarchy, and it is easy to use from curl, a browser, or requests. It suits lightweight CRUD on a single resource, while complex transactions are NETCONF's strength.

3.3.3DevNet learning/testing resources

• DevNet Sandbox lets you connect via API to free test environments for Meraki, Catalyst Center, IOS XE, and more without owning hardware. Use it for learning, PoCs, and verifying scripts (the benefit is safe practice without touching production).
• Code Exchange (a catalog of reusable samples/repos), Learning Labs (hands-on tutorials), API docs (per-platform references), and forums are all provided. A realistic approach to a requirement is "first try it in Sandbox, reuse a template from Code Exchange, and confirm the endpoint in the docs."

Suppose you automate operations for a fleet of IOS XE routers and receive two tasks: "(1) from a script, quickly update just one interface's description on a router; (2) push several routing/ACL changes as a single change, and if even one fails midway, abort everything and roll back." First, confirm the target router has netconf-yang and restconf enabled and ip http secure-server configured. Task (1) is lightweight CRUD on a single resource, so RESTCONF fits: sending PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2 with JSON {"ietf-interfaces:interface": {"description": "..."}} performs a partial update in a few lines from curl or requests (use PUT to replace the whole resource, GET to only read). Doing a whole-resource PUT here risks clearing fields you did not send, so the key judgment is PATCH for a partial update. Task (2), by contrast, requires a transactional bulk change with rollback on failure, which is hard to guarantee with RESTCONF's one-shot CRUD; the right answer is NETCONF's datastores. You stack changes into the candidate datastore via <edit-config>, commit to running if all is well, and discard candidate (leaving running intact) on failure—giving you atomicity. Before you have hardware in hand, the safe path is not to fire at production but to verify responses in the DevNet Sandbox IOS XE environment and reuse a Code Exchange template first. The decision axis, then, is "RESTCONF (with the right HTTP method) for lightweight one-shot CRUD; NETCONF (candidate -> commit) for atomic bulk changes," with the model (YANG) acting as the shared type both of them use.

3.3.4Section summary

• IOS XE/NX-OS open a programmable entry point on the device via netconf-yang/restconf, handling configuration/state as structured data
• YANG is the shared model (types), NETCONF is XML/SSH with datastores for transactions, and RESTCONF is HTTP+JSON/XML with CRUD <-> HTTP methods (PATCH for partial update)
• Use DevNet's Sandbox (free test env), Code Exchange, Learning Labs, and API docs to try safely without touching production and reuse templates