REST APIs and SDN controllers are the tools that let data centre networks be programmed and automated like a smartphone app, rather than managed one command at a time. For someone studying for the 350-601 exam, understanding these concepts is essential because Cisco has shifted nearly all modern data centre automation — configuration, monitoring, troubleshooting — to API-driven models. This chapter explains what REST APIs are, how SDN controllers fit in, and exactly what the exam expects you to know.
Jump to a section
A simple way to picture REST APIs and SDN Controllers
Think about booking a hotel room for a night. You call the front desk, and the receptionist asks for your name, credit card, and dates. They check the paper ledger, manually find an available room, write down your details, and hand you a metal key. That is the old way — like managing a network device by logging into its command line interface (CLI) and typing every command by hand. Now imagine a different system: you open a hotel booking app on your phone. The app sends a tiny message — 'POST /bookings' with JSON data: '{"guest": "Alex", "dates": "May 1–2", "room_type": "suite"}'. The hotel’s central booking server receives that message, checks availability in a database, reserves the suite, and replies: '{"confirmation": "ABC123", "room": 405}'. You never spoke to a human. The app standardised the request, the server processed it automatically, and you got a predictable response. The server’s API (Application Programming Interface) is like the hotel’s digital front desk — it defines exactly what messages the app can send and what replies it will get. The physical hotel network still exists — rooms have doors, keys, and cleaning staff — but everything above that is automated through that single central system. In data centre networking, REST APIs (Representational State Transfer APIs) work the same way: they let software talk to network controllers like Cisco APIC or DCNM using standardised messages over HTTP (the same protocol web browsers use), so operators can automate tasks that once required manually typing commands into dozens of switches.
To understand REST APIs and SDN controllers, you first need to know what an API is. An Application Programming Interface (API) is a set of rules that allows one piece of software to talk to another. Think of it like a waiter in a restaurant: you (the client) tell the waiter what you want (a request), the waiter communicates that to the kitchen (the server), and the kitchen returns your food (the response). The API defines the menu — the specific things you can ask for and the format of your request.
A REST API (Representational State Transfer API) is a specific type of API that uses standard web methods called HTTP verbs. The four most common verbs are: GET (retrieve information), POST (create something new), PUT (update or replace something), and DELETE (remove something). Each verb is paired with a Uniform Resource Identifier (URI), which is like a web address that identifies a specific resource. For example, a request to 'GET /api/v1/interfaces/GigabitEthernet1/1' might return the configuration and status of that interface. The data is usually formatted in JSON (JavaScript Object Notation), which looks like '{"name": "GigabitEthernet1/1", "status": "up", "speed": "10 Gbps"}'. JSON is designed to be easy for both humans and machines to read.
Now, what does this have to do with SDN (Software-Defined Networking)? Traditionally, each network device — router, switch, firewall — has its own operating system and command-line interface (CLI). To change a configuration across one hundred switches, an engineer would have to log into each one individually and type commands. That is slow, error-prone, and does not scale. SDN separates the control plane (the brains that decide where traffic goes) from the data plane (the hardware that forwards packets). The control plane is centralised into an SDN controller — a piece of software that has a global view of the entire network. The controller uses REST APIs to communicate with the network devices and with management applications.
In the context of the 350-601 exam, you need to know two specific SDN controllers: Cisco Application Policy Infrastructure Controller (APIC) and Cisco Data Center Network Manager (DCNM). Cisco APIC manages the Application Centric Infrastructure (ACI) architecture. In ACI, you define policies (rules about what applications are allowed to communicate) on the APIC via its REST API, and the APIC automatically pushes those policies to all the switches in the fabric. This means you never log directly into a switch to configure it. Cisco DCNM (now often called Cisco Nexus Dashboard) manages traditional NX-OS switches in a data centre. It also exposes a REST API that can automate tasks like VLAN creation, interface configuration, and firmware upgrades across hundreds of switches from a single point.
Why does this matter? Automation. A typical data centre might have thousands of switches. If a security vulnerability is discovered and a workaround requires disabling a certain protocol on every switch, doing that manually could take days. With REST APIs and an SDN controller, you could write one script that sends the same API call to the controller for every affected switch, and the change is applied in minutes. The controller also provides centralised monitoring: you can use the API to query the status of every device, interface, and policy in the entire fabric without logging into anything.
The exam expects you to understand the common REST API methods (GET, POST, PUT, DELETE) and their corresponding CRUD operations (Create, Read, Update, Delete). You should also know that REST APIs are stateless — every request from the client to the server must contain all the information the server needs to understand and process the request. The server does not remember previous interactions. Authentication is typically handled through tokens or credentials passed in the HTTP header. Finally, you need to know that both APIC and DCNM support HTTP and HTTPS (the secure version), and that you typically authenticate using a username and password or an API key, getting back a token that you include in subsequent requests.
Identify the Resource
You decide what you want to interact with — a tenant, a switch interface, an endpoint group. In a REST API, this is referred to as the resource, and it is represented by a URI like '/api/node/class/fvTenant.json'.
Select the HTTP Method
Choose GET to retrieve data, POST to create a new resource, PUT to update an existing one, or DELETE to remove one. This matches the CRUD operation you need.
Authenticate the Request
Send your credentials (username and password) to the controller's authentication endpoint (e.g., '/api/aaaLogin.json'). The controller returns a token. Include that token in the HTTP header (often as a cookie) for all subsequent requests.
Send the Request with the Payload
Format your data as JSON (e.g., '{"fvTenant": {"attributes": {"name": "Production"}}}'). Send the HTTP request using a tool like Postman, curl, or a Python script. The request goes to the controller's API endpoint.
Interpret the Response
The controller sends back an HTTP response with a status code (e.g., 200 for success) and a JSON body containing the result or error details. You check the status code and parse the JSON to confirm the operation succeeded or to debug failures.
Automate the Process
Wrap steps 1–5 in a script (e.g., Python with the 'requests' library) that loops through multiple resources or runs on a schedule. This eliminates the need for manual CLI access and enables true automation.
A real-world scenario: You are a junior data centre engineer at a company that runs a large online retail platform. The company has deployed Cisco ACI across two data centre sites, each with 50 leaf switches and 10 spine switches. The APIC controller runs in a high-availability cluster. Your boss asks you to automate the quarterly security audit: you need to verify that all switches have a specific access control list (ACL) applied to all ports in the 'web-tier' endpoint group.
Step 1: You open Postman (a free tool for testing APIs) and craft a GET request to the APIC REST API. The URI looks like 'https://apic-mgmt-ip/api/node/class/fvTenant.json'. You authenticate with your credentials and receive a JSON response listing all tenants.
Step 2: You use the tenant name 'Production' to build a new GET request: 'https://apic-mgmt-ip/api/node/class/fvAEPg.json?query-target-filter=eq(fvAEPg.name,"web-tier")'. The response includes the distinguished name (DN) of the web-tier endpoint group.
Step 3: You write a Python script that uses the 'requests' library to call the APIC API. The script loops through all leaf switches in the fabric. For each leaf, it sends a GET request to retrieve the current ACL configuration on each port. The script checks if the required ACL is present. If it is missing, the script sends a POST request to apply it. All of this happens programmatically without logging into a single switch.
Step 4: You schedule this Python script to run every week using a cron job. The script generates a report in JSON format, listing each switch, the status of the ACL (present/missing), and whether any changes were made.
What you actually do as an IT professional:
You use tools like Postman, curl, or Python to test and send REST API calls.
You read API documentation from Cisco (the APIC REST API documentation is published online) to learn the exact URIs, parameters, and JSON payloads.
You handle authentication by first sending a POST request to '/api/aaaLogin.json' with your username and password, receiving a session token, and then including that token in the 'Cookie' header of all subsequent requests.
You interpret HTTP status codes: 200 OK means success, 201 Created means a resource was created, 400 Bad Request means you sent a malformed request, 401 Unauthorised means your credentials are invalid, 404 Not Found means the resource does not exist, and 500 Internal Server Error means the controller had a problem.
You test API calls in a lab environment before running them in production, because a bad API call could misconfigure the entire fabric.
You use the 'query-target-filter' and 'query-target' parameters in APIC API calls to narrow down the returned data and avoid pulling all the data from a large fabric at once.
The 350-601 exam tests REST APIs and SDN controllers in several specific ways. Expect roughly 5–10% of the questions to come from this objective (5.2). The exam is multiple-choice, multi-select, and drag-and-drop format. Cisco often asks you to identify which HTTP verb (GET, POST, PUT, DELETE) corresponds to a given operation. For example, they might ask: 'Which HTTP method is used to modify an existing configuration object?' The correct answer is PUT (or PATCH for partial updates, but the exam typically sticks to PUT). They also love to ask about the difference between POST and PUT: POST creates a new resource, PUT updates/replaces an existing one.
Another common question type: 'Which SDN controller is used in a Cisco ACI environment?' The answer is APIC. For traditional NX-OS data centre switches, the controller is DCNM (or Nexus Dashboard). They may also ask about the role of the controller: 'What is the primary function of an SDN controller?' The answer is to centralise the control plane and provide a single point of configuration and monitoring.
Traps to watch for:
They might list 'SSH' or 'Telnet' as a way to automate configuration. These are not API-based. SSH is used for manual CLI access, not for programmatic automation with REST APIs.
They might describe a scenario where an engineer logs into each switch one by one and ask if that is automation. It is not — automation implies programmatic, repeatable processes without manual intervention.
They might mix up the APIC and DCNM roles. Remember: APIC is for ACI, DCNM is for standalone NX-OS.
They might ask about authentication for REST APIs: the typical method is to send a POST request with credentials and receive a token, then include that token in subsequent requests. They might also mention HTTP Basic Authentication (sending username:password base64-encoded in the header), which is simpler but less secure.
They might test your understanding of JSON vs XML. The exam tends to focus on JSON as the primary data format for REST APIs, but they might also mention XML (eXtensible Markup Language) as another option. Know that JSON is more common because it is lighter and easier to parse.
Key terms to memorise:
REST API (Representational State Transfer Application Programming Interface)
HTTP verbs: GET, POST, PUT, DELETE
CRUD: Create (POST), Read (GET), Update (PUT), Delete (DELETE)
URI (Uniform Resource Identifier)
JSON (JavaScript Object Notation)
APIC (Application Policy Infrastructure Controller)
DCNM (Data Center Network Manager)
Stateless (each request is independent)
Token-based authentication
HTTP status codes (200, 201, 400, 401, 404, 500)
The exam will not ask you to write code or remember specific API URI syntax from memory. But you need to understand the logical flow: client (script or tool) sends HTTP request to controller's API, controller processes it and sends back HTTP response. The payload is typically JSON. The controller then translates the API call into device-level commands (like NX-OS CLI) and pushes them to the relevant network devices.
Finally, they may ask about 'northbound' and 'southbound' interfaces. The REST API is a northbound interface — it faces the applications and administrators. The protocols used to communicate with the physical or virtual network devices (like OpenFlow, CLI, or NETCONF) are southbound interfaces. This distinction is important in SDN architecture. The APIC and DCNM use their own southbound protocols (e.g., OpFlex for ACI, or direct NX-API for Nexus switches) to push configurations.
REST APIs use HTTP verbs (GET, POST, PUT, DELETE) to perform CRUD operations on network resources represented as URIs.
Cisco APIC is the SDN controller for ACI fabrics and uses a REST API for all configuration and monitoring tasks.
Cisco DCNM (Nexus Dashboard) is the SDN controller for standalone NX-OS switches in traditional data centre deployments.
An SDN controller centralises the control plane, enabling automation across hundreds of devices from a single software platform.
Authentication to a Cisco REST API typically requires a POST request with credentials to obtain a session token used in subsequent requests.
HTTP status codes like 200 (OK) and 201 (Created) indicate success, while 4xx codes indicate client errors and 5xx codes indicate server errors.
These come up on the exam all the time. Here's how to tell them apart.
Cisco APIC
Used exclusively with ACI (Application Centric Infrastructure) fabric
Configures the entire fabric as a single logical entity using policies
Requires ACI-compatible leaf and spine switches
Cisco DCNM
Used with standalone NX-OS switches in traditional data centre deployments
Manages each switch individually or in groups, not as a fabric
Works with any Cisco Nexus switch running NX-OS
REST API (API call method)
Programmatic access via HTTP verbs (GET, POST, PUT, DELETE)
Data formatted in JSON or XML
Stateless and scalable for automation
CLI (Command Line Interface)
Manual typing of text commands (e.g., 'show running-config')
Output is plain text specific to the device OS
Stateful (you are logged into a session) and not designed for automation
GET method
Used to retrieve existing data (Read operation)
Does not change any state on the server
Idempotent: multiple identical requests return the same result
POST method
Used to create new resources (Create operation)
Changes server state by adding new data
Not automatically idempotent: each request may create a duplicate resource
Mistake
REST APIs are only used for monitoring, not for making configuration changes.
Correct
REST APIs can both read (GET) and write (POST, PUT, DELETE) data. They are fully capable of configuring network devices through the controller.
Beginners often associate APIs with pulling statistics because many monitoring tools use them. They don't realise that POST and PUT can change configurations.
Mistake
An SDN controller is a physical hardware appliance that you plug into the network like a switch.
Correct
An SDN controller is a software application, often running as a virtual machine or a container. It can be deployed on commercial hardware or virtualised platforms.
The word 'controller' sounds like a physical device, similar to a 'switch' or 'router', leading to this misunderstanding.
Mistake
You can use any random REST API call from Google or a blog post without worrying about the specific API version.
Correct
REST APIs are versioned. For example, the APIC API URI often includes '/api/mo/' or '/api/node/'. Using the wrong version or syntax can cause the request to fail or produce unexpected results.
People think of APIs as universal standards, but each vendor defines its own API structure and versioning scheme. Cisco publishes its API documentation for a reason.
Mistake
The APIC controller directly pushes configuration changes to switches in real-time, so manual configuration on a switch is still needed sometimes.
Correct
In an ACI fabric, all configuration is done through the APIC. Manual configuration on individual switches is not supported and will be overwritten by the APIC. The fabric pulls its configuration from the APIC.
This misconception stems from familiarity with traditional networking, where you configure each device individually. ACI is a policy-driven system where the controller is authoritative.
Mistake
JSON is the only data format that REST APIs use, so there is no reason to learn about XML.
Correct
REST APIs can return data in JSON, XML, or even plain text. While JSON is dominant, some Cisco controllers still support XML (e.g., DCNM with older API versions). The exam may test your awareness of both.
Beginners focus on the most common format and ignore alternatives, but the exam likes to test completeness of knowledge.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A REST API is the interface (the language) used to communicate with the SDN controller. The SDN controller is the software that manages the network. You use the REST API to tell the SDN controller what to do.
No, the exam does not require you to write code. But you must understand the logical flow of API calls and the purpose of JSON payloads. Familiarity with basic scripting concepts helps in real-world work but is not tested directly.
REST APIs use HTTP (port 80) or HTTPS (port 443). Cisco APIC and DCNM typically use HTTPS for secure communication.
Yes, many Cisco NX-OS switches have their own NX-API that supports REST calls. But for centralised management across many switches, DCNM is used as the controller that exposes a REST API.
Stateless means every request from the client must contain all the information the server needs to process it. The server does not store any session data about previous requests. Authentication tokens must be sent with each request.
You can use a lab environment (like Cisco DevNet sandbox) that provides a virtual APIC or DCNM for testing. Tools like Postman allow you to safely send API calls and see the responses without risking production traffic.
You've finished REST APIs and SDN Controllers. Continue through the 350-601 study guide to build a complete picture of the exam.
Done with this chapter?