In modern network engineering, automation is no longer optional—it's a core competency. The 200-301 exam tests your understanding of REST APIs because they are the foundation for programmable networks, allowing you to manage devices programmatically rather than via CLI. This chapter demystifies REST APIs from a network engineer's perspective, covering HTTP methods, status codes, data formats (JSON), and how Cisco devices expose APIs like the IOS XE RESTCONF interface. By mastering these concepts, you'll be prepared for automation questions on the exam and ready to integrate APIs into real-world network operations.
Jump to a section
Imagine you're at a restaurant with a menu (the API). The menu lists available dishes (resources) with descriptions (data models). You, the customer, are the client application. The waiter (HTTP request) takes your order to the kitchen (the server). You can perform several actions: GET a menu item to read its description, POST a new custom dish, PUT to replace an entire dish with a new recipe, PATCH to update just the spice level, or DELETE to remove an item from the menu. Each order includes a header with your table number (authentication token) and a note about allergies (content-type). The kitchen responds with a status: 200 OK (dish ready), 201 Created (new dish made), 204 No Content (dish removed), 400 Bad Request (invalid order), 401 Unauthorized (not your table), 403 Forbidden (chef refuses), 404 Not Found (dish not on menu), or 500 Internal Server Error (kitchen fire). The response includes the actual dish (data) in a standardized format—like a burger always comes in a box with a label (JSON). The kitchen is stateless: it doesn't remember your previous orders; each request is independent. You can also ask for specific details using query parameters, like '?vegetarian=true' to filter dishes. This mirrors REST APIs: clients send HTTP requests to manipulate resources identified by URLs, using standard methods and receiving structured responses, all without the server maintaining session state.
What is a REST API?
REST (Representational State Transfer) is an architectural style for designing networked applications. It relies on stateless, client-server communication, typically over HTTP. A REST API exposes resources (like interfaces, routes, or device configurations) as URLs, and clients perform operations using standard HTTP methods: GET (read), POST (create), PUT (replace), PATCH (partial update), DELETE (remove). The server responds with a status code and often a body containing data in a format like JSON or XML.
Why REST APIs for Networking?
Traditional network management uses CLI (command-line interface) or SNMP, which are human-centric and often slow for automation. REST APIs allow programmatic access to network devices, enabling configuration management, monitoring, and orchestration at scale. Cisco devices running IOS XE, IOS XR, or NX-OS support REST APIs via RESTCONF, NETCONF, or native APIs like the Cisco IOS XE REST API. The 200-301 exam focuses on understanding REST API concepts, not vendor-specific implementations, but you should know how they apply to Cisco devices.
HTTP Methods and Status Codes
GET: Retrieve a resource. Idempotent and safe. Example: GET /api/interface/GigabitEthernet1 returns the interface configuration.
POST: Create a new resource. Not idempotent. Example: POST /api/interface with JSON body to create a new VLAN interface.
PUT: Replace an entire resource. Idempotent. Example: PUT /api/interface/GigabitEthernet1 with full JSON to overwrite its configuration.
PATCH: Apply a partial update to a resource. Not necessarily idempotent. Example: PATCH /api/interface/GigabitEthernet1 with only 'description' field.
DELETE: Remove a resource. Idempotent. Example: DELETE /api/interface/GigabitEthernet1.
Common HTTP status codes for REST APIs: - 200 OK: Successful GET, PUT, PATCH. - 201 Created: Successful POST (new resource created). - 204 No Content: Successful DELETE or update with no response body. - 400 Bad Request: Malformed syntax or invalid data. - 401 Unauthorized: Missing or invalid authentication. - 403 Forbidden: Authenticated but not authorized. - 404 Not Found: Resource does not exist. - 405 Method Not Allowed: HTTP method not supported for that resource. - 500 Internal Server Error: Server-side error.
Data Formats: JSON and XML
REST APIs commonly use JSON (JavaScript Object Notation) or XML (eXtensible Markup Language) for data exchange. JSON is lightweight and easier for humans and machines to read. Example JSON for an interface:
{
"interface": {
"name": "GigabitEthernet1",
"description": "Uplink to Core",
"enabled": true,
"ip-address": "192.168.1.1",
"subnet-mask": "255.255.255.0"
}
}XML is more verbose but supports namespaces. Cisco IOS XE devices often use YANG models to define the structure of configuration data, and RESTCONF uses JSON or XML encoding based on YANG.
RESTCONF and NETCONF
Cisco 200-301 may reference RESTCONF and NETCONF as protocols for network configuration management: - NETCONF (RFC 6241): Uses SSH or TLS, XML-based, supports operations like get, edit-config, and lock/unlock. It is more robust for transactional changes. - RESTCONF (RFC 8040): Uses HTTP/HTTPS, supports JSON and XML, simpler and more web-friendly. It maps YANG data models to URLs.
Both use YANG (Yet Another Next Generation) data modeling language to define the structure of configuration and state data. YANG models are like schema for network devices.
Authentication and Security
REST APIs on network devices require authentication. Common methods:
HTTP Basic Auth: Username and password in the Authorization header (base64 encoded). Not secure without HTTPS.
Token-based: Obtain a token via login endpoint, then include it in subsequent requests.
API Keys: Pre-shared key in header or query parameter.
Always use HTTPS to encrypt traffic. Cisco devices support TLS/SSL for RESTCONF.
IOS CLI Verification Commands
Although REST APIs are not CLI-based, you can verify API readiness on Cisco IOS XE devices:
show running-config | include restExample output if RESTCONF is enabled:
restconfTo check HTTP/HTTPS server status:
show ip http server statusExample output:
HTTP server status: Enabled
HTTP server port: 80
HTTP server authentication method: local
HTTP server access class: 0
HTTP server base path: /level/15/exec/
...For HTTPS:
show ip http secure server statusInteraction with Related Protocols
REST APIs often work alongside:
- SNMP: For monitoring, but REST APIs provide more granular control.
- CLI: Traditional management; automation via REST APIs reduces manual CLI work.
- Ansible/Chef/Puppet: Configuration management tools that can use REST APIs to push configs.
- Python scripts: Libraries like requests make HTTP calls to REST APIs.
On the exam, know that REST APIs are part of the automation and programmability domain, focusing on HTTP methods, status codes, JSON structure, and the difference between RESTCONF and NETCONF.
Identify the API Endpoint
The first step in using a REST API is knowing the URL (endpoint) of the resource you want to interact with. For a Cisco IOS XE device, the RESTCONF base URL is typically `https://<device-ip>/restconf/data`. The specific path depends on the YANG model. For example, to get interface configurations, the URL might be `/restconf/data/ietf-interfaces:interfaces`. Always verify the base URL and supported resources from the device documentation or by sending a GET request to the root.
Construct the HTTP Request
Choose the appropriate HTTP method (GET, POST, PUT, PATCH, DELETE) based on the operation. Include headers: `Content-Type` (e.g., `application/yang-data+json` for RESTCONF), `Accept` (desired response format), and `Authorization` (e.g., `Basic base64encodedcredentials`). For POST and PUT, include a JSON or XML body. For example, a GET request to retrieve all interfaces: `GET /restconf/data/ietf-interfaces:interfaces` with headers `Accept: application/yang-data+json` and `Authorization: Basic YWRtaW46Y2lzY28=`.
Send the Request and Receive Response
Use a tool like Postman, curl, or a Python script to send the request. The server processes it and returns an HTTP status code and possibly a body. For a successful GET, you get 200 OK with the data. For POST creating a new interface, you get 201 Created with the new resource URL in the `Location` header. For DELETE, you get 204 No Content. If there's an error, check the status code and response body for details (e.g., 400 Bad Request with error message).
Parse the Response Data
The response body is typically JSON or XML. Parse it to extract needed information. For example, a GET response might contain a list of interfaces with their configurations. Use JSON parsing libraries (e.g., Python's `json` module) to convert the response into a dictionary and access fields. For automation, you can then process the data—like checking if an interface is up or modifying its configuration based on the parsed values.
Handle Errors and Retry
Check the HTTP status code. If it's 4xx (client error), review your request: verify authentication, URL, data format, and required fields. If it's 5xx (server error), the device might be overloaded or the API temporarily unavailable. Implement retry logic with exponential backoff (e.g., wait 1s, 2s, 4s) and a maximum number of retries. Log errors for troubleshooting. For idempotent methods (GET, PUT, DELETE), retrying is safe; for POST, ensure you handle duplicate creation (e.g., by checking if resource already exists).
Verify the Change on the Device
After a successful POST, PUT, PATCH, or DELETE, verify the change by performing a GET on the resource. For example, after creating a new VLAN interface, send a GET request to confirm it exists with the correct parameters. Alternatively, use the CLI to check: `show running-config interface Vlan100`. This step ensures the API operation had the intended effect and helps catch any discrepancies between the API and actual device state.
Scenario 1: Automating Interface Configuration Rollout
A large enterprise deploys a new branch office with 50 Cisco Catalyst 9300 switches. Instead of manually configuring each switch via CLI, the network automation team writes a Python script that uses the IOS XE RESTCONF API to push a standard interface configuration template. The script loops through a CSV file containing switch IPs, hostnames, and VLAN assignments. For each switch, it sends a PUT request to /restconf/data/ietf-interfaces:interfaces with the JSON payload for each interface. The script checks for 201 or 204 responses and logs errors. This reduces provisioning time from 2 hours per switch to 15 minutes total. The team also implements error handling: if a switch returns a 400 error, the script pauses and alerts the engineer to check the data (e.g., invalid VLAN ID). Without REST APIs, this would require SSHing into each device and pasting commands, prone to typos and inconsistencies.
Scenario 2: Real-time Network Monitoring via REST API
A data center operator needs to monitor interface utilization across 200 Nexus switches. They use a Python application that sends GET requests every 5 minutes to /restconf/data/openconfig-interfaces:interfaces/interface/state/counters on each switch. The response includes byte counters, errors, and discards. The app parses JSON and pushes metrics to a time-series database (e.g., InfluxDB) for visualization in Grafana. A critical consideration is the API rate limit: sending too many requests can overwhelm the switch CPU. The team implements a staggered schedule, querying switches in batches of 20 with a 10-second delay between batches. They also monitor the device's CPU via SNMP to avoid impact. If a switch becomes unresponsive (HTTP timeout), the app retries twice then alerts. This system replaced an SNMP-based polling solution that was slower and less granular.
Scenario 3: Configuration Backup and Compliance
A managed service provider (MSP) uses REST APIs to back up configurations of 500 routers nightly. A Python script sends GET requests to /restconf/data/Cisco-IOS-XE-native:native (the entire running config) and saves the JSON response to a version-controlled repository. The script also compares the current config against a baseline using JSON diffing; any unauthorized changes trigger an alert. Performance consideration: retrieving the entire config is a large payload (could be >1MB). The script uses compression (gzip) in the request headers to reduce bandwidth. Misconfiguration example: if the API endpoint changes due to a firmware upgrade, the script fails silently; the team adds a health check that first sends a GET to a known endpoint (e.g., /restconf/data/ietf-interfaces:interfaces) to verify the API is reachable before attempting backup.
The 200-301 exam objective 6.3 is 'Describe REST APIs for networking.' This is a foundational concept question, not a deep dive into specific Cisco API implementations. You need to know:
What REST stands for and its principles (stateless, client-server, uniform interface).
Common HTTP methods (GET, POST, PUT, PATCH, DELETE) and their typical uses.
Common HTTP status codes (200, 201, 204, 400, 401, 403, 404, 500).
The role of data formats (JSON, XML) in API communication.
The difference between RESTCONF and NETCONF (RESTCONF uses HTTP, NETCONF uses SSH; both use YANG models).
Common Wrong Answers and Why Candidates Choose Them
'REST APIs use SNMP for transport.' – Wrong because REST uses HTTP/HTTPS, not SNMP. SNMP is a separate management protocol. Candidates confuse different network management methods.
'PUT and POST are the same.' – Wrong because PUT is for replacing a resource (idempotent), POST is for creating a new resource (not idempotent). Candidates often mix them up.
'HTTP 200 means the resource was created.' – Wrong because 200 is for successful GET, PUT, PATCH; 201 is for creation. Candidates remember 200 as 'success' but not the specific semantics.
'REST APIs require stateful connections.' – Wrong because REST is stateless; each request contains all necessary information. Candidates associate APIs with stateful protocols like TCP.
Specific Values and Command Outputs
The exam may show a REST API URL like /restconf/data/ietf-interfaces:interfaces and ask which resource is being accessed.
You might see a JSON snippet and be asked to identify the value of a specific key.
Know that RESTCONF uses either JSON or XML encoding, but typically JSON for simplicity.
Decision Rule for Scenario Questions
When asked to choose the correct HTTP method for an operation:
If the scenario says 'retrieve' or 'read' -> GET.
If 'create' or 'add' -> POST.
If 'replace entirely' -> PUT.
If 'modify only certain fields' -> PATCH.
If 'delete' -> DELETE.
For status codes:
Successful read/update -> 200.
Successful creation -> 201.
Successful deletion -> 204.
Client error (bad request) -> 400.
Authentication failure -> 401.
Authorization failure -> 403.
Resource not found -> 404.
Server error -> 500.
REST stands for Representational State Transfer; it is stateless and uses HTTP.
Common HTTP methods: GET (read), POST (create), PUT (replace), PATCH (partial update), DELETE (remove).
HTTP status codes: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.
Data formats: JSON (lightweight, key-value pairs) and XML (verbose, hierarchical).
RESTCONF uses HTTP/HTTPS; NETCONF uses SSH; both use YANG data models.
Authentication for REST APIs often uses HTTP Basic Auth or tokens; always use HTTPS.
REST APIs enable programmatic network automation, replacing manual CLI configuration.
These come up on the exam all the time. Here's how to tell them apart.
RESTCONF
Uses HTTP/HTTPS
Supports JSON and XML
Stateless operations
Simpler, web-friendly
Uses YANG data models
NETCONF
Uses SSH or TLS
XML only
Can be stateful (locks, sessions)
More robust for transactional changes
Also uses YANG data models
Mistake
REST APIs are only for web applications, not network devices.
Correct
Cisco devices (IOS XE, NX-OS) support REST APIs (RESTCONF) for configuration and monitoring, making them central to network automation.
Candidates think of REST as a web-only technology because they first encounter it in web development contexts.
Mistake
PUT and PATCH are interchangeable.
Correct
PUT replaces the entire resource; PATCH applies a partial update. Using PUT for a partial change may delete unspecified fields.
Both are used for updates, so candidates assume they are synonyms.
Mistake
HTTP 401 means the resource is forbidden.
Correct
401 is Unauthorized (missing/invalid credentials); 403 is Forbidden (authenticated but not permitted).
The word 'unauthorized' is misleading; candidates conflate it with lack of permission.
Mistake
REST APIs use XML exclusively.
Correct
REST APIs support multiple formats, but JSON is more common due to its simplicity. RESTCONF can use either JSON or XML.
Older network APIs (like SOAP) used XML, so candidates assume REST follows the same pattern.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A REST API is like a menu at a restaurant. The menu lists available dishes (resources) and how to order them (HTTP methods). You place an order (request) and the kitchen (server) returns your dish (response). It's stateless, meaning the kitchen doesn't remember your previous orders. For network engineers, it's a way to programmatically configure and monitor devices using standard web technologies.
Common methods include HTTP Basic Authentication (sending username:password in base64 in the Authorization header) or token-based authentication (first POST to a login endpoint to get a token, then include it in subsequent requests). Always use HTTPS to encrypt credentials. On Cisco IOS XE, you can enable RESTCONF with the 'restconf' command and configure local or AAA authentication.
REST is an architectural style; RESTCONF is a specific protocol that implements REST principles for network configuration management using YANG data models. RESTCONF defines how to map YANG data to URLs and HTTP methods. So, all RESTCONF APIs are RESTful, but not all REST APIs are RESTCONF.
No, the device must have an IP address reachable via HTTP/HTTPS. Typically, you configure a management interface with an IP address and enable the HTTP/HTTPS server. If the device is unreachable, you cannot use the API. For out-of-band management, you might use a console or SSH as alternative.
YANG (Yet Another Next Generation) is a data modeling language used to define the structure of configuration and state data on network devices. RESTCONF uses YANG models to define valid URLs, data types, and constraints. For example, the 'ietf-interfaces' YANG model defines the structure of interface configuration. Without YANG, the API would have no standard way to represent data.
You can use tools like Postman (graphical), curl (command-line), or even a web browser for GET requests. For example, in Postman, you set the HTTP method, enter the URL, add headers (like Authorization and Content-Type), and send the request. The response shows the status code and body. This is great for learning and debugging.
Common pitfalls include: forgetting to enable the API on the device (e.g., 'restconf' command missing), using HTTP instead of HTTPS (security), sending malformed JSON (validate with a linter), not handling rate limiting (device CPU overload), and assuming idempotency for POST (multiple POSTs may create duplicates). Always test with a single device first, and implement robust error handling.
You've just covered REST APIs for Networking — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?