APIs are the backbone of network automation, and the CCNA 200-301 exam (objective 6.3) expects you to understand how to test and verify REST APIs using tools like Postman. In real network engineering, you'll use Postman to validate API calls against controllers like Cisco DNA Center or SD-WAN vManage before writing production scripts. Mastering Postman isn't just about clicking buttons—it's about understanding HTTP methods, status codes, and authentication flows that are foundational to programmable networks.
Jump to a section
Imagine you're a customer at a high-tech restaurant. The menu is your API documentation—it lists all the dishes (endpoints) you can order. You (the client) tell the waiter (Postman) what you want. The waiter writes your order on a ticket (the HTTP request), specifying the table number (URL), the type of order (GET for 'what's today's special?', POST for 'I'd like to order this dish', PUT for 'change my side dish', DELETE for 'cancel my order'), and any special instructions (headers and body). The waiter then takes the ticket to the kitchen (the server). The kitchen prepares the dish and sends back a plate (the response) with a status code: 200 (OK, here's your food), 201 (Created, your new dish has been added to the menu), 204 (No Content, your order was cancelled successfully), 400 (Bad Request, you ordered something not on the menu), 401 (Unauthorized, you didn't show your membership card), 403 (Forbidden, you're not allowed to order from the VIP menu), 404 (Not Found, that dish doesn't exist), or 500 (Internal Server Error, the kitchen is on fire). The waiter brings the plate back to you, and you can see exactly what the kitchen sent. If something goes wrong, you can check the ticket (request) and the plate (response) to debug. In the same way, Postman lets you build requests, send them to a server, and inspect the response—making it an essential tool for testing and troubleshooting REST APIs in network automation.
What is Postman and Why Does CCNA Care?
Postman is a graphical API client that allows you to construct, send, and analyze HTTP requests without writing code. For CCNA 200-301, the exam objective 6.3 specifically covers 'Interpret the results of a REST API call to a network device.' This means you need to understand the structure of HTTP requests and responses, how to authenticate, and how to interpret status codes and payloads. Postman is the tool Cisco recommends for testing APIs against devices like Cisco DNA Center, IOS XE devices with RESTCONF, or Meraki cloud controllers.
HTTP Methods and Their Use in Network Automation
REST APIs use standard HTTP methods to perform CRUD operations (Create, Read, Update, Delete). In the context of network devices:
GET: Retrieve configuration or state information. For example, GET /api/v1/interface to list all interfaces on a device.
POST: Create a new resource, such as adding a VLAN or a static route. The request body contains the resource details in JSON or XML.
PUT: Update an existing resource. You send the entire resource representation; if it doesn't exist, some APIs create it.
PATCH: Partial update—only send the fields that need changing. Less common in early CCNA but used in newer controllers.
DELETE: Remove a resource, like deleting an ACL or a user.
Cisco's exam expects you to know which method to use for a given operation. A common trap is confusing POST and PUT: POST is for creating, PUT is for updating/replacing.
Anatomy of an HTTP Request in Postman
When you create a request in Postman, you specify:
URL: The endpoint, e.g., https://10.1.1.1/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1.
Method: Dropdown to select GET, POST, PUT, PATCH, DELETE.
Headers: Key-value pairs like Content-Type: application/yang-data+json and Accept: application/yang-data+json for RESTCONF. Also, authentication headers like Authorization: Basic base64(username:password) or token-based X-Auth-Token: <token>.
Body: For POST, PUT, PATCH, you provide the payload. In Postman, you can choose raw JSON, XML, or form-data.
Anatomy of an HTTP Response
The response includes:
- Status Code: A three-digit number indicating the result. Key ones for CCNA:
- 200 OK: Successful GET, PUT, PATCH.
- 201 Created: Successful POST (resource created).
- 204 No Content: Successful DELETE or PUT with no body returned.
- 400 Bad Request: Malformed syntax (e.g., invalid JSON).
- 401 Unauthorized: Missing or invalid authentication.
- 403 Forbidden: Authenticated but not authorized.
- 404 Not Found: Resource doesn't exist.
- 409 Conflict: Resource already exists (e.g., duplicate VLAN).
- 500 Internal Server Error: Server-side issue.
- Headers: Response headers like Content-Type.
- Body: The returned data, often in JSON or XML. For a GET request, this might be the interface configuration.
Authentication Methods
Cisco devices support multiple authentication methods for REST APIs:
Basic Authentication: Username and password sent in the Authorization header as base64-encoded string. Not secure over HTTP; use HTTPS.
Token-Based Authentication: Obtain a token via a POST to an auth endpoint (e.g., /api/system/v1/auth/token for DNA Center), then include the token in subsequent requests as X-Auth-Token header.
Certificate-Based: Some devices require client certificates.
Postman simplifies this with the Authorization tab, where you can select the type and fill in credentials; Postman automatically generates the header.
Using Postman with RESTCONF
RESTCONF is a protocol defined in RFC 8040 that uses HTTP methods to manipulate YANG data stores. On Cisco IOS XE devices, you enable RESTCONF with:
restconfUnder the ip http server or ip http secure-server configuration. Then, you can use Postman to send requests to the RESTCONF root, e.g., https://device-ip/restconf/data. The Content-Type and Accept headers should be application/yang-data+json or application/yang-data+xml. For example, to get the hostname:
Method: GET
URL: https://10.1.1.1/restconf/data/Cisco-IOS-XE-native:native/hostname
Headers: Accept: application/yang-data+json
Auth: Basic
Response (200 OK):
{
"Cisco-IOS-XE-native:hostname": "Router1"
}Interpreting Results
When you get a response, check:
Status Code: Is it 2xx success? If not, the error code gives a clue.
Response Body: For GET, does it contain the data you expected? For POST, does it return the created resource?
Headers: Look for Content-Type to ensure the format matches.
A common CCNA exam scenario: you send a POST to create a VLAN but get a 400 Bad Request. The reason might be missing required fields in the JSON body, or incorrect Content-Type header.
Postman Collections and Environments
Postman allows you to group requests into collections (like a test suite). You can also define variables in environments (e.g., dev, prod) so you can switch between different device IPs or tokens without changing each request. This is crucial for real-world automation where you test against multiple devices.
Verifying with show Commands
After a successful API call, you can verify the change on the device using traditional CLI:
show running-config | include hostnameOr via the API again with a GET request. For example, after creating a VLAN via POST, do a GET to confirm.
Common Pitfalls
Wrong HTTP method: Using GET to create a resource (should be POST).
Missing or wrong headers: For RESTCONF, you must include Content-Type and Accept set to application/yang-data+json.
Incorrect URL path: The YANG data path must match the device's YANG model.
Authentication failure: Forgetting to enable HTTPS or using wrong credentials.
SSL certificate errors: Postman warns; you can disable SSL verification in settings for lab testing, but never in production.
Install and Launch Postman
Download Postman from postman.com and install it. Launch the application. You'll see a workspace where you can create requests. No configuration is needed to start; Postman works out of the box for HTTP/HTTPS requests. For CCNA, you'll typically use the desktop app, but there's also a web version. First step is to get familiar with the interface: the Request tab, the method dropdown, the URL bar, and the Send button.
Configure a Basic GET Request
In the URL bar, enter a REST API endpoint. For example, if you have a Cisco DNA Center sandbox, use `https://sandboxdnac.cisco.com/dna/system/api/v1/auth/token` (but for GET, use something like `https://sandboxdnac.cisco.com/dna/intent/api/v1/network-device`). Set the method to GET. In the Authorization tab, select Basic Auth and enter the username and password. Click Send. Observe the response: status code 200, and the body contains a list of network devices in JSON. This verifies the API is reachable and your credentials work.
Understand the Response Structure
After sending the GET request, examine the response. The status code is at the top (e.g., 200 OK). Below, the response body is displayed in formatted JSON. Look for keys like `response` or `data`. For example, DNA Center returns an array of devices under `response`. Each device has attributes like `hostname`, `managementIpAddress`, `platformId`. Also check the response headers for `Content-Type`. If the status code is 401, your authentication is wrong. If 404, the URL is incorrect. This step teaches you to interpret what the server returns.
Send a POST Request to Create a Resource
Change the method to POST. For RESTCONF, use a URL like `https://10.1.1.1/restconf/data/Cisco-IOS-XE-native:native/vlan` (assuming the device supports it). In the Headers tab, add `Content-Type: application/yang-data+json` and `Accept: application/yang-data+json`. In the Body tab, select raw and JSON format, then enter a payload like `{"Cisco-IOS-XE-native:vlan": [{"id": 100, "name": "TestVlan"}]}`. Set Authorization to Basic with device credentials. Click Send. Expect a 201 Created status code. This confirms the VLAN was created. Then verify with a GET request to the same URL.
Use Environment Variables for Reusability
Click the gear icon in the top right and select Manage Environments. Create a new environment called 'Lab'. Add variables like `base_url` with initial value `https://10.1.1.1` and `token` with initial value empty. In your request, replace the hardcoded URL with `{{base_url}}/restconf/data/...`. For token-based auth, you can set the `X-Auth-Token` header to `{{token}}`. Then, use a Pre-request Script to automatically fetch a token and set the variable. This simulates real-world automation where you don't hardcode credentials.
Interpret Error Responses
Deliberately send a malformed request. For example, omit the `Content-Type` header or send invalid JSON. Observe the response: you'll get a 400 Bad Request with an error message in the body like 'Invalid JSON' or 'Missing required field'. Also try sending a POST to a read-only resource (e.g., GET endpoint) to see a 405 Method Not Allowed. Understanding these errors is critical for the exam; they often ask what a specific status code means. For instance, a 401 vs 403: 401 means no authentication or bad credentials; 403 means authenticated but not permitted.
In a typical enterprise, a network automation engineer uses Postman to prototype API calls before writing production scripts with Python or Ansible. For example, when integrating with Cisco DNA Center, the engineer first tests the authentication endpoint to get a token, then uses that token to fetch the list of devices. They might create a Postman collection with all necessary API calls for provisioning a new branch router: get device details, create a template, apply the template, and verify the configuration. Postman's environment variables allow them to switch between lab and production by changing the base URL and credentials.
Another scenario: managing Meraki networks. The Meraki dashboard API uses RESTful endpoints. An engineer uses Postman to test calls like GET /organizations/{orgId}/networks to list networks, or POST /networks/{networkId}/wireless/ssids to create an SSID. They can save these requests in a collection and share with the team via Postman's cloud sync.
Performance considerations: When testing against a production device, be mindful of rate limits. Some controllers limit API calls per second. Postman's built-in runner can simulate load, but for production, you'd throttle requests. Also, always use HTTPS to encrypt credentials.
Misconfiguration consequences: If you accidentally use PUT instead of POST, you might overwrite an existing resource. For example, sending a PUT to a VLAN endpoint with an existing VLAN ID could replace its configuration. Worse, a DELETE request to a wrong URL could remove critical network objects. Always double-check the method and URL before hitting Send. In one real incident, an engineer deleted the default gateway via API, causing a network outage. Postman's history feature helps audit past requests.
For CCNA 200-301 objective 6.3, the exam tests your ability to interpret REST API results, not to memorize Postman UI details. Expect scenario-based questions: 'A network engineer sends a POST request to create a VLAN. The response status is 400. What is the most likely cause?' The answer choices might include 'The VLAN already exists' (409 Conflict), 'The request body is malformed' (400), or 'The device does not support RESTCONF' (501 Not Implemented). Candidates often confuse 400 and 409: 400 is bad request syntax, 409 is a conflict like duplicate resource.
Another common trap: confusing HTTP methods. A question might describe a task to update an interface description. Candidates might choose PUT instead of PATCH. But the exam expects that PUT replaces the entire resource, while PATCH updates only the fields specified. However, many Cisco APIs use PUT for updates, so check the API documentation context.
Specific values to remember: Status codes 200, 201, 204, 400, 401, 403, 404, 409, 500. Also know that RESTCONF uses specific headers: Content-Type and Accept set to application/yang-data+json or application/yang-data+xml. The exam might show a partial request with missing headers and ask why it failed.
Elimination strategy: For 'what does this status code mean?' questions, eliminate any answer that doesn't match the code's definition. For example, 403 is not about missing credentials (that's 401) but about insufficient permissions. If the question mentions the user is authenticated but gets an error, choose 403 over 401.
Finally, know the difference between RESTCONF and NETCONF: RESTCONF uses HTTP and JSON/XML, while NETCONF uses SSH and XML. The exam may ask which tool is appropriate for a REST API test—Postman is for REST, not NETCONF.
Postman is a graphical API client used to test REST APIs by sending HTTP requests and inspecting responses.
HTTP methods: GET (read), POST (create), PUT (update/replace), PATCH (partial update), DELETE (remove).
Common status codes: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 500 Internal Server Error.
RESTCONF uses headers Content-Type and Accept set to application/yang-data+json or application/yang-data+xml.
Authentication methods: Basic Auth (base64-encoded credentials) and token-based (X-Auth-Token header).
Postman environments allow variable substitution (e.g., {{base_url}}) to switch between lab and production.
Always verify API changes with a subsequent GET request or CLI show commands.
These come up on the exam all the time. Here's how to tell them apart.
Postman
Graphical user interface with request builder.
Supports environments and variables for easy switching.
Built-in collection runner for test sequences.
Automatically formats JSON responses for readability.
Easier for beginners and quick testing.
cURL
Command-line tool, no GUI.
No built-in variable management; uses shell variables.
Scriptable via bash, but no dedicated runner.
Output is raw; requires piping to formatters like jq.
Better for automation scripts and CI/CD pipelines.
Mistake
Postman can only test GET requests.
Correct
Postman supports all HTTP methods: GET, POST, PUT, PATCH, DELETE, and more.
Candidates often only see GET examples and assume that's all it does.
Mistake
A 400 status code means the resource already exists.
Correct
400 Bad Request indicates malformed syntax (e.g., invalid JSON). A conflict due to existing resource returns 409.
Both are client errors, but they have distinct meanings.
Mistake
You must write code to use Postman.
Correct
Postman is a GUI tool; no coding required. You can also write scripts for automation, but basic use is click-and-send.
Many new engineers think API testing requires programming.
Mistake
Postman only works with JSON.
Correct
Postman supports multiple formats: JSON, XML, form-data, binary, etc. It can also handle different content types.
JSON is common, but Postman is format-agnostic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Enable RESTCONF on the device with the 'restconf' command. Ensure HTTPS is enabled (ip http secure-server). In Postman, in the Authorization tab, select Basic Auth and enter the device username and password. Postman will base64-encode them and add the Authorization header. Alternatively, for token-based auth (e.g., DNA Center), send a POST to the auth endpoint, extract the token from the response, and set it as an environment variable. Then use that variable in the X-Auth-Token header.
For RESTCONF, you need both Content-Type and Accept headers set to 'application/yang-data+json' (or '+xml' for XML). Content-Type tells the server the format of the request body (for POST/PUT/PATCH), and Accept tells the server the desired format for the response. Without these headers, the server may return a 400 Bad Request or an unsupported media type error.
The URL path is incorrect. RESTCONF URLs follow the pattern: https://device-ip/restconf/data/<yang-module>:<container>/<leaf>. Ensure the YANG module and data path match the device's YANG models. Use a GET to the root /restconf/data to discover available resources. Also check that the device supports RESTCONF and that the restconf command is configured.
Use a 'dry-run' or 'validate' feature if the API supports it, but most Cisco APIs don't. Instead, you can use Postman's 'Pre-request Script' to simulate the request and check the payload, but it won't validate against the server. Alternatively, test against a lab device or a sandbox. Always verify with a GET after the POST to confirm the resource was created as expected.
401 Unauthorized means the request lacks valid authentication credentials (e.g., no token or wrong password). 403 Forbidden means the server understood the request but refuses to authorize it; the client is authenticated but does not have permission to access the resource. For example, a user may be logged in but not an admin.
No, Postman is for HTTP-based APIs like RESTCONF. NETCONF uses SSH (port 830) and XML messages, not HTTP. To test NETCONF, you need a NETCONF client like yangcli or Python's ncclient. The CCNA exam tests both, but Postman is specific to REST APIs.
In Postman, click the 'Code' button (</>) in the request panel. This shows the request as it would be sent in various languages (cURL, Python, etc.). You can also enable the Postman Console (View > Show Postman Console) to see the exact request and response headers and body.
You've just covered Testing REST APIs with Postman — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?