Nexnet AcademyV1 · alpha
← CourseAutomation~6 min read

Network automation: JSON, REST APIs & controllers

Why automate

Configuring 200 switches by hand is slow, inconsistent and error-prone. Automation gives you repeatability (the same result every time), speed, and auditability (the change is in version control). The goal isn't to remove engineers - it's to remove copy-paste mistakes and 2 a.m. typos.

Data formats: JSON and YAML

Automation speaks structured data. JSON uses key/value pairs and is what most REST APIs return: {"hostname": "sw1", "vlans": [10, 20]}. YAML is the same idea in a more human-friendly, indentation-based form, common for config files and playbooks. Both separate the data (variables) from the template (the config shape).

REST APIs

A REST API lets software read and change device or controller state over HTTP. Methods map to actions: GET reads (safe, no change), POST creates, PUT/PATCH update, DELETE removes. Status codes report the result: 200 OK, 201 created, 401 unauthorized, 404 not found. Requests usually carry an auth token and a JSON body.

Controllers, SDN and tools

Software-defined networking splits the control plane (the brain deciding paths) from the data plane (the hardware forwarding packets). A controller (e.g. Cisco Catalyst Center, SD-WAN) programs many devices centrally through its API. Config-management tools like Ansible and Terraform apply desired state idempotently - running them twice yields the same result, not a double change.

Concept cards

JSON

A key/value data format used by most REST APIs.

A labelled form both humans and software can read.

Idempotent

An operation that gives the same result no matter how many times it runs.

Pressing a floor button in a lift - pressing it again changes nothing.

Control vs data plane

The decision-making layer vs the packet-forwarding layer; SDN centralizes the control plane.

The dispatcher vs the delivery trucks.

Now try it
M16-01REST, JSON & Controllers
Start the mission →