REST APIs and JSON for Network Engineers

The command line is a conversation for humans. REST APIs are the conversation for programs, and once a controller sits in front of your network (see Controller-Based Networking and SDN), REST is how your scripts, dashboards, and automation tools ask it to do things. CCNA domain 6 expects you to understand REST and the JSON it speaks. This article covers the HTTP verbs and how they map to actions, status codes, authentication, and JSON structure, all grounded in real requests made from a Linux host against a live Cisco Modeling Labs controller. It is part of the Network Automation guide.

What REST Actually Is

REST (Representational State Transfer) is an architectural style for APIs that runs over ordinary HTTP. You address a resource with a URL, choose an HTTP verb to say what you want to do to it, and the server responds with a status code and a body (almost always JSON). That is the whole idea: no special protocol, just HTTP used deliberately. Because it is HTTP, you can call it with curl, with Python's requests, or from any tool that can make a web request, which is exactly why it won as the northbound interface for controllers.

HTTP Verbs Map to CRUD

The four things you can do to data (Create, Read, Update, Delete) map cleanly onto four HTTP verbs. Learn this mapping; the exam tests it directly.

Authentication: Basic vs Token

An API you can call without credentials is an API anyone can call, so the first request is almost always about proving who you are. Two patterns dominate. Basic authentication sends a username and password with every request (over HTTPS, so it is encrypted in transit). Token-based authentication trades your credentials once for a token, then sends that token on every subsequent request; if the token leaks it can be scoped and expired, which is why it is preferred for automation.

Here is a real token exchange against the Cisco Modeling Labs controller from a Linux host. A POST to the authenticate endpoint hands over the credentials and gets back a JSON Web Token (JWT):

j@llmbits:~$ curl -sk -X POST https://192.168.88.158/api/v0/authenticate \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"..."}'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ...(JWT token)

That opaque string is the token. Every following request carries it in an Authorization: Bearer header, and the controller trusts it instead of re-checking the password. This is exactly the flow the automation labs on the site use, and the Automation Labs (auto-04 and auto-05) walk through it hands-on.

Reading JSON: An Array

With the token in hand, a GET asks for a list of resources. The controller returns a JSON array, which is an ordered list wrapped in square brackets:

j@llmbits:~$ curl -sk https://192.168.88.158/api/v0/labs \
  -H "Authorization: Bearer $TOKEN"
["181e4455-d9ad-49a9-9e88-956692eeb459","79c2e69f-75b3-4988-b566-ae641f6c2eb0",
 "4353e423-743b-4c62-8e98-5bd140468763","6929be76-3bd6-4b35-9fb3-79398408f0a4"]

Each element is a string (a lab ID). An array is how APIs hand you a collection: iterate over it in your script and act on each item.

Reading JSON: An Object

Ask for one specific resource and you get a JSON object: a set of key-value pairs in curly braces. Piping the response through python3 -m json.tool pretty-prints it so the structure is readable:

j@llmbits:~$ curl -sk https://192.168.88.158/api/v0/labs/6929be76-... \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool
{
    "state": "STARTED",
    "created": "2026-07-10T22:37:00+00:00",
    "lab_title": "PingLabz CCNA Services Lab",
    "owner_username": "admin",
    "node_count": 5,
    "link_count": 6,
    "id": "6929be76-3bd6-4b35-9fb3-79398408f0a4",
    "groups": []
}

This one response contains every JSON data type the CCNA asks about, so it is worth annotating:

JSON also has booleans (true/false) and null. The rules that trip people up: keys are always strings in double quotes, strings use double quotes (never single), no trailing comma after the last pair, and whitespace is ignored (the pretty-printing above is purely for humans). Get one comma wrong and the whole document fails to parse, which is why you validate JSON before sending it.

Status Codes

Every response carries a numeric status code that tells your script what happened, grouped by first digit.

The 4xx codes are the ones you meet most while writing automation. A 401 usually means your token expired (re-authenticate); a 400 means you sent bad JSON (validate it); a 404 means you have the URL wrong.

A Note on RESTCONF

Everything above is a generic REST API on a controller. There is also a standards-based REST API that runs directly on network devices, called RESTCONF: it exposes the device's configuration and operational data as REST resources, structured by YANG models, and returns YANG-modeled JSON. It is the device-level cousin of the controller API. In full transparency, the IOL router images used in the lab here do not ship RESTCONF, which is why these captures target the CML controller's own REST API instead. On a real IOS XE box you would enable restconf and hit /restconf/data/... with the same verbs, headers, and JSON you have seen here. The concepts transfer exactly; only the endpoint changes. RESTCONF and its sibling NETCONF are where CCNP picks up the thread.

Why REST Matters for Network Engineers

You do not have to become a developer, but you do have to be able to read an API response and make a call. The moment your network has a controller, the CLI stops being the only interface, and the tasks that used to mean SSHing into fifty boxes become a loop over a JSON array. Being able to authenticate, GET a resource, read the JSON, and POST a change is the difference between automating your job and doing it by hand forever. The configuration-management tools in Ansible vs Puppet vs Chef are, underneath, making these same REST calls for you.

FAQ

What is the difference between REST and RESTCONF?

REST is the general style (HTTP verbs, URLs, JSON) that any web API can use. RESTCONF is a specific standard that applies REST to network-device configuration, structuring the data with YANG models. RESTCONF is REST, specialized for devices.

Does REST have to use JSON?

No, REST can return XML too, and RESTCONF supports both. But JSON has become the default because it is lighter and maps directly onto the data structures in Python and JavaScript. The CCNA focuses on JSON.

Why use a token instead of sending my password every time?

A token can be scoped, expired, and revoked without changing your password, and it limits exposure if a single request is intercepted. Sending credentials on every call means every call carries your full secret. Tokens are the safer automation pattern.

Do I need to know curl for the exam?

You should be able to read a REST call and identify the verb, the resource, and the expected response. curl is just a convenient way to show that on one line; the concepts (verb, URL, headers, body, status code) are what matter.

Key Takeaways

REST is HTTP used deliberately: a verb (GET/POST/PUT/PATCH/DELETE) acting on a URL, returning a status code and JSON. The verbs map to CRUD. Authenticate first, prefer a token over sending credentials repeatedly, and read the status code before trusting the body. JSON is objects ({}), arrays ([]), strings, numbers, booleans, and null, with strict comma and quote rules. RESTCONF is the same idea aimed at devices via YANG. Put it into practice in the Automation Labs, and see the Network Automation guide for the full path.