REST APIs in Networking

1. What Is a REST API?

A REST API (Representational State Transfer Application Programming Interface) is an architectural style for building web services that allows software systems to communicate over HTTP. In networking, REST APIs provide a programmatic interface to network devices and controllers — allowing applications, scripts, and automation platforms to read and modify network state without a human typing CLI commands.

REST APIs use standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources — logical objects such as devices, interfaces, VLANs, or routing tables. Resources are identified by URIs (Uniform Resource Identifiers), and data is exchanged in a structured format, overwhelmingly JSON in modern networking implementations.

REST Characteristic	Meaning
Stateless	Each request is self-contained — the server holds no client session state between requests; all information needed to process a request must be in the request itself (authentication token, parameters)
Client-Server	Clear separation between the client (requesting application, Postman, Python script) and the server (controller, device exposing the API)
Uniform Interface	Standard HTTP methods and resource URIs provide a consistent interface across all REST APIs — the same mental model works whether you are calling DNA Center or Meraki or NSO
Resource-Based	Everything is a resource (a device, an interface, a VLAN, a user); each resource has a unique URI; operations are performed on resources using HTTP methods

2. HTTP Methods – The REST Verbs

REST APIs use standard HTTP methods to express the operation being performed on a resource. These methods map directly to CRUD operations (Create, Read, Update, Delete) — the four fundamental data operations.

HTTP Method	CRUD Operation	Purpose	Body?	Idempotent?
GET	Read	Retrieve a resource or list of resources; does not modify anything	No	Yes — repeated GETs return the same result
POST	Create	Create a new resource; sends a JSON body describing the new object	Yes	No — multiple POSTs create multiple resources
PUT	Update (replace)	Replace an entire existing resource with the provided body; all fields must be included	Yes	Yes — same PUT produces same result if repeated
PATCH	Update (partial)	Partially update a resource — only the fields provided in the body are changed; other fields are unchanged	Yes	Yes (if designed correctly)
DELETE	Delete	Remove a resource identified by the URI	No (usually)	Yes — deleting an already-deleted resource still returns success or 404

2.1 HTTP Method Examples – VLAN Resource

  Base URI: https://dnacenter.corp.local/api/v1/vlans

  ── GET all VLANs ──────────────────────────────────────────────────────
  GET  /api/v1/vlans
  → Returns a JSON array of all VLANs
  → Safe operation — no changes made

  ── GET a specific VLAN ────────────────────────────────────────────────
  GET  /api/v1/vlans/10
  → Returns details for VLAN 10 only

  ── POST — Create a new VLAN ───────────────────────────────────────────
  POST /api/v1/vlans
  Body: { "vlan_id": 50, "name": "Finance", "state": "active" }
  → Creates VLAN 50
  → Returns 201 Created with the new resource URI

  ── PUT — Replace VLAN 50 completely ──────────────────────────────────
  PUT  /api/v1/vlans/50
  Body: { "vlan_id": 50, "name": "Finance-Updated", "state": "active" }
  → Replaces the entire VLAN 50 resource

  ── PATCH — Update only the name ──────────────────────────────────────
  PATCH /api/v1/vlans/50
  Body: { "name": "Finance-Dept" }
  → Only the name field changes; vlan_id and state unchanged

  ── DELETE — Remove VLAN 50 ───────────────────────────────────────────
  DELETE /api/v1/vlans/50
  → Removes VLAN 50
  → Returns 204 No Content (success, no body)

3. HTTP Status Codes

Every REST API response includes an HTTP status code that indicates whether the operation succeeded, failed, and why. Status codes are three-digit numbers grouped by their leading digit into five classes.

Code Range	Category	Meaning
1xx	Informational	Request received, processing continues — rarely seen in REST API responses
2xx	Success	The request was successfully received, understood, and accepted
3xx	Redirection	Further action required; the resource has moved to a new URI
4xx	Client Error	The request was malformed or unauthorised — the client made a mistake
5xx	Server Error	The server failed to process a valid request — server-side problem

3.1 Commonly Tested Status Codes

Code	Name	When Returned	Common REST Context
200	OK	Request succeeded and response body is returned	Successful GET, PUT, PATCH — response includes the resource
201	Created	Resource successfully created; Location header points to new URI	Successful POST that creates a new resource
204	No Content	Request succeeded but there is no response body	Successful DELETE or PUT that returns nothing
400	Bad Request	The request body is malformed — invalid JSON, missing required field	POST/PUT with badly formatted JSON body
401	Unauthorised	Authentication credentials missing or invalid	Missing or expired API token; wrong password
403	Forbidden	Authenticated but not authorised to perform this action	Valid token but insufficient privileges (read-only user trying DELETE)
404	Not Found	The requested resource does not exist	GET or DELETE on a VLAN ID that does not exist
405	Method Not Allowed	HTTP method not supported on this endpoint	Attempting DELETE on a read-only endpoint
409	Conflict	Request conflicts with current resource state	POST to create a VLAN ID that already exists
429	Too Many Requests	Rate limit exceeded — client is sending too many requests too fast	API rate limiting; back off and retry
500	Internal Server Error	The server encountered an unexpected error processing the request	Bug in the controller API; server-side failure
503	Service Unavailable	Server temporarily unable to handle requests	Controller overloaded or in maintenance

401 vs 403: These two codes are frequently confused. 401 Unauthorised means the client has not proved who it is — credentials are missing or invalid (authentication failure). 403 Forbidden means the client has proved who it is but does not have permission to perform the action (authorisation failure). In network API contexts: 401 = wrong token or no token; 403 = valid token but the account lacks the required role or privilege.

4. REST API Request and Response Structure

Every REST API interaction consists of an HTTP request sent by the client and an HTTP response returned by the server. Understanding the structure of both is fundamental to working with any network API.

4.1 HTTP Request Structure

  HTTP Request Components:

  ┌─────────────────────────────────────────────────────────────────────┐
  │  REQUEST LINE                                                        │
  │  POST /api/v1/vlans HTTP/1.1                                        │
  │  ↑     ↑             ↑                                              │
  │  Method  URI          HTTP version                                   │
  ├─────────────────────────────────────────────────────────────────────┤
  │  HEADERS (metadata about the request)                               │
  │  Host: dnacenter.corp.local                                         │
  │  Content-Type: application/json     ← format of the request body   │
  │  Accept: application/json           ← format expected in response  │
  │  X-Auth-Token: eyJhbGci...          ← authentication token         │
  │  Authorization: Bearer eyJhbGci... ← alternative token style       │
  ├─────────────────────────────────────────────────────────────────────┤
  │  BODY (payload — only for POST, PUT, PATCH)                         │
  │  {                                                                   │
  │    "vlan_id": 50,                                                    │
  │    "name": "Finance",                                                │
  │    "state": "active"                                                 │
  │  }                                                                   │
  └─────────────────────────────────────────────────────────────────────┘

4.2 HTTP Response Structure

  HTTP Response Components:

  ┌─────────────────────────────────────────────────────────────────────┐
  │  STATUS LINE                                                         │
  │  HTTP/1.1 201 Created                                               │
  │            ↑                                                         │
  │         Status code and reason phrase                               │
  ├─────────────────────────────────────────────────────────────────────┤
  │  HEADERS                                                             │
  │  Content-Type: application/json                                      │
  │  Location: /api/v1/vlans/50    ← URI of the newly created resource  │
  │  X-RateLimit-Remaining: 998                                          │
  ├─────────────────────────────────────────────────────────────────────┤
  │  BODY (the returned resource in JSON)                               │
  │  {                                                                   │
  │    "vlan_id": 50,                                                    │
  │    "name": "Finance",                                                │
  │    "state": "active",                                               │
  │    "created_at": "2025-03-14T09:14:22Z"                             │
  │  }                                                                   │
  └─────────────────────────────────────────────────────────────────────┘

4.3 JSON – The Standard Data Format

JSON (JavaScript Object Notation) is the dominant data format for REST APIs. It is lightweight, human-readable, and natively supported by every modern programming language. Cisco DNA Center, Meraki, NSO, and virtually all modern network controllers use JSON for API request and response bodies.

  JSON structure rules:
  {
    "key": "string value",          ← String — double quotes required
    "number": 42,                   ← Number — no quotes
    "enabled": true,                ← Boolean — true/false (lowercase)
    "nothing": null,                ← Null value
    "list": [10, 20, 30],           ← Array (ordered list)
    "nested": {                     ← Nested object
      "interface": "Gi0/0",
      "ip": "10.1.1.1"
    },
    "devices": [                    ← Array of objects (very common)
      {"hostname": "R1", "ip": "192.168.1.1"},
      {"hostname": "R2", "ip": "192.168.1.2"}
    ]
  }

  Key JSON rules:
  ✓ Keys MUST be strings in double quotes: "key"
  ✓ Strings MUST use double quotes — single quotes are invalid
  ✓ Trailing commas are NOT allowed: {... "last": "value"}  not  {... "last": "value",}
  ✓ JSON has no comments — unlike YAML
  ✓ Top-level element must be an object {} or array []

5. REST API Authentication

Because REST is stateless, every request must include credentials proving the client's identity. Network APIs use several authentication mechanisms — understanding the difference between them is important for both exam questions and working with real controllers.

5.1 API Keys

An API key is a simple pre-shared string token generated by the API server and issued to a client application. The client includes this key in every request — typically in a custom HTTP header or as a query parameter.

  API Key Authentication:

  ┌──────────────────────────────────────────────────────────────────────┐
  │  Client                              Server (Cisco Meraki)           │
  │                                                                       │
  │  GET /api/v1/devices                                                 │
  │  X-Cisco-Meraki-API-Key: abc123xyz789def456...                       │
  │                        ─────────────────────────────────────────────►│
  │                                                                       │
  │                        ◄─────────────────────────────────────────────│
  │                            200 OK — JSON device list                 │
  └──────────────────────────────────────────────────────────────────────┘

  How Cisco Meraki uses API keys:
  1. Generate in Meraki Dashboard → Account → API Access
  2. Include in every request header: X-Cisco-Meraki-API-Key: <key>
  3. The key identifies the organisation and user permissions

  Characteristics:
  ✓ Simple — one static value, easy to use in scripts
  ✓ No expiry unless manually revoked
  ✗ If the key is leaked, the attacker has permanent access until revoked
  ✗ No granular time-bound sessions
  ✗ Does not scale well for dynamic multi-user environments

5.2 Token-Based Authentication (Session Tokens)

Cisco DNA Center (and similar platforms) use a token-based authentication flow. The client first makes an authentication request with username/password credentials to obtain a time-limited token. This token is then included in subsequent API requests. Tokens expire after a period, requiring re-authentication — making them more secure than static API keys.

  Token-Based Auth — DNA Center Pattern:

  Step 1: Authenticate to get a token
  ───────────────────────────────────────────────────────────────────────
  POST /dna/system/api/v1/auth/token
  Authorization: Basic Base64(admin:password)
  Content-Type: application/json

  Response 200 OK:
  {
    "Token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1..."
  }

  Step 2: Use the token in all subsequent requests
  ───────────────────────────────────────────────────────────────────────
  GET /dna/intent/api/v1/network-device
  X-Auth-Token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

  Response 200 OK:
  {
    "response": [
      { "hostname": "R1", "managementIpAddress": "10.0.0.1", ... },
      { "hostname": "SW1", "managementIpAddress": "10.0.0.2", ... }
    ]
  }

  Token characteristics:
  ✓ Time-limited — typically expires in 60 minutes; limits exposure if leaked
  ✓ Credentials (username/password) transmitted only once, at login
  ✓ Revocable — admin can invalidate tokens server-side
  ✗ More steps than API keys — must handle token refresh/expiry in scripts

5.3 OAuth 2.0

OAuth 2.0 is an industry-standard authorisation framework used by platforms like Cisco Webex, Meraki (for third-party integrations), and many cloud-based network management platforms. Unlike API keys or basic tokens, OAuth 2.0 allows users to delegate access to a third-party application without sharing their password.

  OAuth 2.0 Simplified Flow (Authorization Code Grant):

  User                Client App              Auth Server          Resource API
    │                     │                       │                     │
    │ 1. Click "Connect"  │                       │                     │
    │────────────────────►│                       │                     │
    │                     │ 2. Redirect to auth   │                     │
    │                     │ server login page     │                     │
    │                     │──────────────────────►│                     │
    │ 3. Login + consent  │                       │                     │
    │────────────────────────────────────────────►│                     │
    │                     │ 4. Auth code          │                     │
    │                     │◄──────────────────────│                     │
    │                     │ 5. Exchange code      │                     │
    │                     │ for access token      │                     │
    │                     │──────────────────────►│                     │
    │                     │ 6. Access token       │                     │
    │                     │◄──────────────────────│                     │
    │                     │ 7. API call + token   │                     │
    │                     │────────────────────────────────────────────►│
    │                     │ 8. Protected data     │                     │
    │                     │◄────────────────────────────────────────────│

  Key OAuth terms:
  Access Token   — short-lived token for API calls (typically 1 hour)
  Refresh Token  — longer-lived token to obtain a new access token without re-login
  Scope          — defines what the token permits (read:devices, write:vlans, etc.)

5.4 Authentication Methods Comparison

Method	Complexity	Security	Token Expiry	Common In
Basic Auth	Lowest — username:password encoded in Base64	Low — credentials in every request; Base64 is not encryption	No expiry — always valid	DNA Center initial token request; legacy APIs
API Key	Low — static string in header	Medium — simple but static; leakage = permanent exposure	No expiry unless revoked	Cisco Meraki, many SaaS APIs
Token (Bearer)	Medium — obtain token first, then use it	High — time-limited; credentials not repeated per request	Yes — typically 1 hour	Cisco DNA Center, APIC, NSO
OAuth 2.0	Highest — multi-step flow with redirect	Highest — delegated, scoped, time-limited; user never shares password	Yes — short-lived access tokens + refresh tokens	Cisco Webex, cloud platforms, third-party integrations

6. REST APIs with Cisco DNA Center

Cisco DNA Center (DNAC) is Cisco's network management and automation platform for enterprise campus and branch networks. It exposes a comprehensive REST API through its Intent API — a northbound API that allows external applications to query network state, trigger operations, and configure policies without the DNA Center GUI.

6.1 DNA Center API Architecture

  ┌─────────────────────────────────────────────────────────────────────────┐
  │  External Apps, Automation Scripts, Third-Party Platforms              │
  │  (Python, Postman, Ansible, ServiceNow, custom applications)           │
  └──────────────────────────┬──────────────────────────────────────────────┘
                             │  HTTPS REST (Northbound API)
                             │  /dna/intent/api/v1/...
                             ▼
  ┌─────────────────────────────────────────────────────────────────────────┐
  │                      Cisco DNA Center                                   │
  │  ┌──────────────┐  ┌───────────────┐  ┌─────────────────────────────┐  │
  │  │  Intent API  │  │  Design APIs  │  │  Policy / Assurance APIs    │  │
  │  │  (devices,   │  │  (site hier-  │  │  (QoS, security, analytics) │  │
  │  │  topology)   │  │   archy, templates)                             │  │
  │  └──────────────┘  └───────────────┘  └─────────────────────────────┘  │
  └──────────────────────────┬──────────────────────────────────────────────┘
                             │  Southbound APIs
                             │  (NETCONF, RESTCONF, CLI, SNMP, gRPC)
                             ▼
  ┌─────────────────────────────────────────────────────────────────────────┐
  │  Network Devices — Routers, Switches, APs, WLCs (managed by DNAC)      │
  └─────────────────────────────────────────────────────────────────────────┘

6.2 Common DNA Center API Endpoints

URI	Method	Purpose
`/dna/system/api/v1/auth/token`	POST	Obtain an authentication token (Basic Auth header with credentials)
`/dna/intent/api/v1/network-device`	GET	Retrieve the list of all network devices managed by DNA Center
`/dna/intent/api/v1/network-device/{id}`	GET	Retrieve detailed information for a specific device by its ID
`/dna/intent/api/v1/topology/physical-topology`	GET	Retrieve the physical network topology as a JSON object
`/dna/intent/api/v1/site`	GET / POST	List all sites in the site hierarchy or create a new site
`/dna/intent/api/v1/template-programmer/template`	GET / POST	List or create configuration templates for device provisioning
`/dna/intent/api/v1/interface`	GET	Retrieve interface information for all devices

6.3 DNA Center API Example – Get All Devices

  ── Step 1: Authenticate (get token) ──────────────────────────────────

  curl -X POST https://sandboxdnac.cisco.com/dna/system/api/v1/auth/token \
    -H "Content-Type: application/json" \
    -H "Authorization: Basic $(echo -n 'devnetuser:Cisco123!' | base64)"

  Response:
  {
    "Token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
  }

  ── Step 2: Use token to get device list ──────────────────────────────

  curl -X GET https://sandboxdnac.cisco.com/dna/intent/api/v1/network-device \
    -H "X-Auth-Token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."

  Response (abbreviated):
  {
    "response": [
      {
        "hostname": "asr1001-x.abc.inc",
        "managementIpAddress": "10.10.22.74",
        "platformId": "ASR1001-X",
        "softwareVersion": "16.11.1b",
        "reachabilityStatus": "Reachable",
        "upTime": "69 days, 2:27:27.37",
        "serialNumber": "FXS1932Q1SE"
      },
      {
        "hostname": "cat_9k_1.abc.inc",
        "managementIpAddress": "10.10.22.66",
        "platformId": "C9KV-UADP-8P",
        "softwareVersion": "17.3.1"
      }
    ],
    "version": "1.0"
  }

7. Northbound and Southbound APIs

In a controller-based network, APIs operate at two distinct levels. Understanding this northbound/southbound distinction is a core CCNA exam topic.

Direction	What It Connects	Who Uses It	Example Protocols
Northbound API	Controller → External applications, orchestration systems, business applications	Network engineers, developers, automation scripts, OSS/BSS systems	REST (HTTPS/JSON), GraphQL, gRPC
Southbound API	Controller → Network devices (routers, switches, APs)	The controller itself — pushes config and collects telemetry from devices	NETCONF, RESTCONF, OpenFlow, gRPC/gNMI, SNMP, CLI (SSH)

  ┌──────────────────────────────────────────────────────────────────────┐
  │  Applications / Automation / OSS-BSS                                │
  │  (Python scripts, Ansible, ServiceNow, custom dashboards)           │
  └──────────────────────────┬───────────────────────────────────────────┘
                             │   NORTHBOUND API  (REST/HTTPS/JSON)
                             │   "What do you WANT the network to do?"
                             ▼
  ┌──────────────────────────────────────────────────────────────────────┐
  │  SDN Controller / Network OS                                        │
  │  (Cisco DNA Center, APIC, NSO, OpenDaylight, Cisco SD-WAN)          │
  └──────────────────────────┬───────────────────────────────────────────┘
                             │   SOUTHBOUND API  (NETCONF, RESTCONF, gRPC)
                             │   "HOW to configure the physical devices"
                             ▼
  ┌──────────────────────────────────────────────────────────────────────┐
  │  Physical Network Infrastructure                                    │
  │  (Routers, Switches, Firewalls, APs, WLCs)                          │
  └──────────────────────────────────────────────────────────────────────┘

8. Using Postman with Network APIs

Postman is a popular GUI tool for testing and developing REST API calls without writing code. It allows engineers to build requests, inspect responses, manage authentication headers, and create collections of reusable API calls — making it the standard first step when exploring a new network API.

  Postman Request Setup — DNA Center Get Devices:

  ┌─────────────────────────────────────────────────────────────────────┐
  │  Method:  GET                                                       │
  │  URL:     https://sandboxdnac.cisco.com/dna/intent/api/v1/network-device
  ├─────────────────────────────────────────────────────────────────────┤
  │  Headers Tab:                                                        │
  │  Key              Value                                             │
  │  X-Auth-Token     eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...          │
  │  Content-Type     application/json                                  │
  ├─────────────────────────────────────────────────────────────────────┤
  │  [Send] ──────────────────────────────────────────────────────►     │
  │                                                                     │
  │  Response:  200 OK                                                  │
  │  Body (JSON): { "response": [ {...}, {...} ], "version": "1.0" }    │
  └─────────────────────────────────────────────────────────────────────┘

  Key Postman workflow for DNA Center:
  1. Create a POST request to the auth/token endpoint with Basic Auth
  2. Copy the returned token value
  3. Create GET requests with X-Auth-Token header containing the token
  4. Group related requests into a Postman Collection for reuse
  5. Use Postman environment variables to store the token automatically

  Postman Environment Variable automation (Tests tab of auth POST):
  var token = pm.response.json().Token;
  pm.environment.set("dnac_token", token);
  // Now use {{dnac_token}} in headers of subsequent requests

9. REST API vs NETCONF vs RESTCONF

For the CCNA exam, it is important to understand how REST APIs compare to NETCONF and RESTCONF — three technologies that all provide programmatic access to network devices, but at different levels of the stack and with different design goals.

Feature	REST API	NETCONF	RESTCONF
Level	Northbound — controller/platform API	Southbound — direct device API	Southbound — direct device API (RESTful subset of NETCONF)
Transport	HTTPS (HTTP/1.1 or 2.0)	SSH (port 830) with XML	HTTPS with JSON or XML
Data format	JSON (predominant)	XML only	JSON or XML (YANG-defined)
Data model	Vendor-defined (not standardised)	YANG models (standardised)	YANG models (standardised)
Operations	GET, POST, PUT, PATCH, DELETE	get, get-config, edit-config, commit, lock	GET, POST, PUT, PATCH, DELETE (HTTP-based)
Typical use	Talking to DNA Center, Meraki, SD-WAN from scripts	Direct YANG-based config/telemetry on IOS-XE, IOS-XR	Lighter-weight device config using REST-style calls to YANG models

10. Key Terms Quick Reference

Term	Definition
REST	Representational State Transfer — an architectural style for building HTTP-based APIs; stateless, resource-oriented, uses standard HTTP methods
API	Application Programming Interface — a defined interface through which software applications communicate; in networking, exposes device/controller functions to external programs
URI	Uniform Resource Identifier — the address of a REST resource (e.g., `/api/v1/vlans/10`); a URL is a specific type of URI that includes the scheme and host
HTTP Method	The REST verb specifying the operation: GET (read), POST (create), PUT (replace), PATCH (partial update), DELETE (remove)
Status Code	Three-digit HTTP response code indicating outcome: 2xx = success, 4xx = client error, 5xx = server error; key codes: 200 OK, 201 Created, 204 No Content, 401 Unauthorised, 403 Forbidden, 404 Not Found
JSON	JavaScript Object Notation — the standard REST API data format; human-readable key-value pairs, arrays, and nested objects; keys must be double-quoted strings
API Key	A static pre-shared string token included in API request headers for authentication; simple but no automatic expiry — leakage provides indefinite access until revoked
Token (Bearer)	A time-limited authentication token obtained by logging in with credentials; included in the `X-Auth-Token` or `Authorization: Bearer` header of API requests
OAuth 2.0	An industry-standard authorisation framework that allows users to delegate scoped, time-limited access to third-party applications without sharing passwords; uses access tokens and refresh tokens
DNA Center Intent API	The northbound REST API of Cisco DNA Center; allows external applications to query device inventory, topology, configuration templates, and network policies via HTTPS/JSON
Northbound API	An API that sits above a controller, facing external applications and automation systems; typically REST/JSON; answers "what do you want the network to do?"
Southbound API	An API between a controller and the network devices it manages; typically NETCONF, RESTCONF, gRPC, or CLI (SSH); translates controller intent into device configuration
Postman	A GUI tool for building, testing, and documenting REST API calls; widely used to explore network controller APIs without writing code
Idempotent	An operation that produces the same result when performed multiple times; GET, PUT, DELETE are idempotent; POST is not — multiple POSTs create multiple resources

11. REST APIs in Networking – Practice Quiz

1. A network engineer sends a GET request to `/api/v1/devices` and receives a response. What does the GET method guarantee about the network state?

A. GET requests always return data in XML format B. GET requests automatically refresh the device inventory before returning results C. GET is a read-only, safe, idempotent operation — it retrieves data without modifying any resource on the server; repeated GETs return the same result D. GET requests require an authentication token in the request body

Correct answer is C. GET is defined in HTTP as a safe and idempotent method. Safe means it has no side effects — calling GET on a resource does not create, modify, or delete anything. Idempotent means calling GET multiple times in a row produces the same result as calling it once. These properties make GET the correct method for all read operations in REST APIs. In networking, GET is used to query device inventory, interface status, routing tables, topology, and configuration — operations that should never change the network state.

2. An engineer makes a REST API call and receives HTTP status code 401. What does this indicate, and how does it differ from status code 403?

A. 401 means the resource does not exist; 403 means the server is temporarily unavailable B. 401 means the client has not authenticated — credentials are missing or invalid; 403 means the client has authenticated but does not have permission to perform this specific action C. 401 means too many requests have been sent; 403 means the request body is malformed D. 401 and 403 are functionally identical — both indicate a security rejection

Correct answer is B. The 401 vs 403 distinction is one of the most frequently tested REST API status code questions. 401 Unauthorised means the authentication step failed — the client provided no token, an expired token, or an invalid credential. The fix is to re-authenticate and get a valid token. 403 Forbidden means the authentication succeeded (the server knows who the client is) but the client's account does not have the privilege to perform this operation — for example, a read-only user trying to DELETE a VLAN. The fix is to use an account with the appropriate role, not to re-authenticate.

3. What is the correct HTTP method and expected status code for successfully creating a new VLAN via a REST API?

A. POST to the VLANs collection URI; expected status 201 Created — the POST creates a new resource and the 201 response includes the Location header pointing to the new resource's URI B. GET to the VLANs URI with the VLAN details in the query string; expected status 200 OK C. PUT to the VLANs collection URI; expected status 204 No Content D. PATCH to the VLANs URI with the full VLAN object; expected status 200 OK

Correct answer is A. POST is the correct method for creating a new resource. It is sent to the collection URI (e.g., /api/v1/vlans) with the new resource described in the JSON body. The standard success response for a POST that creates a resource is 201 Created, which typically includes a Location header pointing to the URI of the newly created resource (e.g., /api/v1/vlans/50). 200 OK is for successful GETs and updates; 204 No Content is for successful DELETEs; GET never sends a body. See VLANs for how VLANs are managed in the context of network automation.

4. What is the difference between PUT and PATCH when updating an existing device record via a REST API?

A. PUT is for updating network devices; PATCH is for updating server records B. PUT requires authentication; PATCH is anonymous C. PUT and PATCH are identical — both partially update specific fields of a resource D. PUT replaces the entire resource — all fields must be included in the body; PATCH partially updates — only the fields in the body are changed, other fields remain unchanged

Correct answer is D. This PUT vs PATCH distinction is important for network API work. A PUT request is a full replacement — if you have a device object with hostname, IP, model, and serial number, a PUT requires all four fields in the body even if you only want to change the hostname. Omitting a field in PUT typically nulls it or removes it. A PATCH request is a partial update — you include only the fields you want to change. To update just the hostname, send {"hostname": "new-hostname"} via PATCH and all other fields remain as they are. For large, complex objects, PATCH is more efficient and less error-prone than PUT.

5. In the Cisco DNA Center API authentication flow, why is an authentication token preferred over sending username and password in every request?

A. Tokens are longer than passwords and therefore harder to guess B. Tokens are time-limited — they expire (typically in one hour), limiting the exposure window if intercepted; credentials are only transmitted once to the auth endpoint, not repeated in every API request C. Tokens are stored encrypted on the device; passwords are stored in plaintext D. DNA Center only accepts tokens — it does not support basic authentication for any request

Correct answer is B. Sending username/password in every HTTP request (Basic Auth) means the credentials are transmitted repeatedly across the network — every single API call is a potential exposure point if TLS fails or is misconfigured. Token-based authentication limits this: credentials are sent only once to the /auth/token endpoint. The returned token is used for all subsequent calls. If the token is intercepted, it expires automatically (typically in one hour), limiting the attack window. Tokens can also be revoked server-side instantly, unlike long-lived API keys or passwords.

6. An engineer calls `GET /dna/intent/api/v1/network-device` and receives a 404 Not Found response. What does this mean?

A. DNA Center has no devices registered — the network is empty B. The authentication token has expired and must be renewed C. The URI does not match any known endpoint on this server — likely a typo in the path, wrong API version (v1 vs v2), or the feature is not available on this DNA Center version D. The request method GET is not supported on this endpoint — use POST instead

Correct answer is C. A 404 Not Found response from a server means the server cannot find a resource at the requested URI. In the context of a DNA Center API call, this typically means the URI path is wrong — a typo, incorrect version number (using v2 when v1 is correct, or vice versa), or the endpoint does not exist on the specific DNA Center software version being queried. It does NOT mean the device list is empty — an empty list would return 200 OK with an empty JSON array. Note: 405 Method Not Allowed would indicate the wrong HTTP method, not 404.

7. What is the key security risk of using static API keys compared to time-limited bearer tokens?

A. Static API keys do not expire — if leaked (e.g., accidentally committed to a Git repository), they provide indefinite access to the API until manually revoked; bearer tokens expire automatically, limiting the exposure window B. API keys must be transmitted in the request body, making them visible in server logs; bearer tokens are sent only in encrypted headers C. API keys are limited to read-only operations; bearer tokens can perform write operations D. API keys require a separate OAuth 2.0 exchange before each use; bearer tokens do not

Correct answer is A. The no-expiry nature of static API keys is their most significant security weakness. A key accidentally included in a Git commit, exposed in a log file, or stolen in a breach remains valid indefinitely — the attacker has permanent API access until someone notices and manually revokes the key. Bearer tokens mitigate this risk with automatic expiry: even if a token is intercepted, it only works for a limited time (typically one hour). For long-running automation scripts that need persistent access, the best practice is to implement token refresh logic rather than using static keys.

8. In a controller-based network architecture, what is the difference between a northbound API and a southbound API?

A. Northbound APIs use IPv4; southbound APIs use IPv6 addressing B. Northbound APIs are used by physical routers; southbound APIs are used by virtual machines C. Northbound APIs face the internet; southbound APIs face the internal LAN D. A northbound API faces external applications and automation tools above the controller (REST/JSON — "what do you want the network to do?"); a southbound API faces the network devices below the controller (NETCONF, gRPC, CLI — "how to configure the physical infrastructure")

Correct answer is D. This north/south distinction is a fundamental CCNA exam concept. The north direction points toward the applications, orchestration systems, and humans that consume the controller's services — they interact via high-level northbound APIs (REST/HTTPS/JSON) that abstract the underlying network complexity. The south direction points toward the physical infrastructure — the controller talks to individual devices via lower-level southbound protocols (NETCONF/YANG, RESTCONF, OpenFlow, gRPC, or legacy CLI/SNMP) to configure them and collect telemetry. Cisco DNA Center's Intent API is a northbound API; NETCONF running to IOS-XE devices is a southbound API.

9. Which JSON syntax error is present in the following request body? `{ 'vlan_id': 10, "name": "Sales", }`

A. The value 10 should be in quotes: "10" B. Two errors: vlan_id key uses single quotes (JSON requires double quotes for all keys and strings); and there is a trailing comma after the last property which is invalid JSON C. The object must start with an array bracket [ not a curly brace D. JSON keys cannot contain underscores — use camelCase instead: vlanId

Correct answer is B. The sample JSON { 'vlan_id': 10, "name": "Sales", } contains two distinct syntax errors that would cause an API to return 400 Bad Request. First, 'vlan_id' uses single quotes — JSON strictly requires double quotes for all keys and string values; single quotes are invalid and will cause a JSON parse error. Second, the trailing comma after "Sales" is invalid in JSON (unlike JavaScript, JSON does not permit trailing commas). The number 10 without quotes is correct — JSON represents numbers without quotes. Underscores in key names are perfectly valid JSON.

10. A Python script calls the DNA Center API to get all network devices. The script successfully retrieved a token but the device list request returns 200 OK with this response: `{"response": [], "version": "1.0"}`. What does this indicate?

A. The authentication failed — 200 OK with empty response means the token is invalid B. The request was sent to the wrong endpoint — an empty array indicates a 404 error was returned in disguise C. The API call succeeded completely — 200 OK is a successful response; the empty array means no devices are currently registered in DNA Center (not an error — it is a valid, correct result) D. The response is paginated — the first page is empty but subsequent pages contain the devices

Correct answer is C. A 200 OK status code with an empty array in the response body is a completely valid and successful API interaction. The server processed the request correctly, authenticated the client, queried the database, and returned the result — which happens to be an empty list because no devices are registered. This is distinct from a 404 (URI not found), 401 (bad token), or 500 (server error). An empty response array is not an error — it is meaningful data. This understanding is important when writing scripts that check for successful API calls: always check the HTTP status code first, then interpret the response body.

← Back to Home