Cisco IOS XE REST API and NETCONF

To understand the Cisco IOS XE REST API and NETCONF/YANG, first you must understand the problem they solve. Traditionally, to configure a Cisco router or switch (a network device), you would open a terminal program, log in, and type specific commands one at a time. This is called the Command-Line Interface (CLI). It is like building a car by telling an engineer every single step: 'Turn this bolt. Now turn that bolt. Now check the oil.' It works, but it is slow, error-prone, and difficult to automate.

Imagine you manage 500 devices. Using CLI, you would have to log into each one, type the same commands 500 times, and pray you did not make a typo on the 499th device. This is not scalable. This is where Programmable Interfaces come in. They allow you to manage many devices using software, scripts, or tools. The two main approaches for Cisco devices are the REST API and NETCONF/YANG.

Let's start with REST API. REST stands for Representational State Transfer. It is a style of designing web services. When you visit a website, your browser uses HTTP (Hypertext Transfer Protocol) — that's the 'language' of the web. A REST API lets you send HTTP requests to a server (like a router) to read or change its configuration. The Cisco IOS XE REST API is a specific version of this that runs on Cisco's operating system (IOS XE). You send commands like GET (to read data), POST (to create new data), PUT (to update data), and DELETE (to remove data). The server responds in a structured format called JSON (JavaScript Object Notation) or XML (eXtensible Markup Language). JSON looks like this: {"hostname": "Router1", "interface": "GigabitEthernet0/0"}. It is easy for computers and humans to read.

Now, what about NETCONF and YANG? NETCONF stands for Network Configuration Protocol. It is a standard protocol (a set of rules) for installing, manipulating, and deleting the configuration of network devices. Think of it as a specialised delivery truck for network configurations. YANG stands for Yet Another Next Generation. It is a data modelling language — it describes the structure of the data. If NETCONF is the truck, YANG is the map that tells the truck exactly where to go and what to pick up. YANG defines what configurations are valid on a device. For example, a YANG model for an interface says: 'an interface has a name, an IP address, and a status that can be 'up' or 'down'.' This is a strict, precise definition.

The key difference from REST API is that NETCONF is designed specifically for network devices. It uses Remote Procedure Calls (RPCs) — basically, 'calls' to the device that say 'do this operation.' It operates over SSH (Secure Shell) or TLS (Transport Layer Security) for security. NETCONF also has a feature called 'datastores' — separate, predictable places to store different types of configuration data. The three main datastores are:

Why does this matter? Because when you use CLI, you change the running config directly, and if you make a mistake, the device might break immediately. With NETCONF, you edit the candidate config, validate it, and then commit it. If the validation fails, the device stays untouched.

Cisco IOS XE supports both REST API and NETCONF/YANG. The REST API is simpler for basic tasks like reading data or making quick changes. NETCONF/YANG is more powerful for complex, automated configuration management, especially when you manage hundreds of devices. The 200-901 exam tests your understanding of these concepts, not deep programming. You need to know what each technology is for and when you would choose one over the other.

An IT professional managing a network for a mid-sized company (say, 300 employees across three offices) receives a request from the security team: 'We need to update the ACL (Access Control List) on every router to block a new malicious IP address.' ACLs are rules that allow or block traffic. In the past, this person would open a terminal, connect to each router via SSH, type 'config t', then paste the ACL commands, then type 'exit', then save the configuration. For three routers, that is tedious. For twenty routers, it is a whole morning's work with high risk of human error.

Using a programmable approach, the IT professional writes a simple Python script that uses the Cisco IOS XE REST API. The script does the following:

The whole process for ten routers takes less than two minutes. The script can be reused any time the security team makes a request. If the team uses a network management tool like Ansible (automation tool) or Python with the ncclient library (for NETCONF), they could also use NETCONF. They would define the desired ACL configuration using a YANG model. They would connect to each device via NETCONF, push the candidate configuration, validate it, and commit it. The result is the same — the change is made — but NETCONF gives stronger guarantees that the change is syntactically correct before it is applied.

Another common real-world task is collecting inventory data. A network manager needs to know the model, serial number, and software version of every device. Using CLI, they would log into each device and type 'show version'. Using the REST API, they send a single GET request to the device's '/api/v1/device/info' endpoint and receive a JSON response with all that data. They can then write a script that loops through all device IP addresses and aggregates the data into a spreadsheet or a dashboard.

In the exam, you will not be asked to write a script. But you will be asked to interpret what such a script does. For example, if you see a script that sends a PUT request to an API endpoint with a JSON payload, you should know that it is updating a resource, not reading it. The real-world takeaway is that these technologies let you treat your network as a programmable system, not a collection of boxes that need manual typing.