Network Automation Fundamentals: APIs, Data Formats, and Controller-Based Networking

Why Manual CLI Configuration Does Not Scale

Every configuration example throughout this series so far has relied on typing commands directly into the CLI, discussed earlier in this series. This approach works well for a handful of devices, but becomes impractical and error-prone at the scale of a modern data center or large enterprise network with hundreds or thousands of devices — manually repeating the same configuration change across a thousand switches is slow, tedious, and highly susceptible to typos and inconsistency between devices.

The Shift from CLI to API-Driven Management

Rather than a human typing commands meant to be read by another human, API (Application Programming Interface)-driven management allows software to configure and query network devices programmatically, using structured requests and responses instead of human-readable command-line text.

Traditional CLI approach:
A human manually types:
  interface gigabitethernet 0/1
  description Uplink to Core
  no shutdown
-- Not easily parsed or generated by software
-- without fragile text-pattern matching

API-driven approach:
A script sends a structured request:
  PUT /interfaces/GigabitEthernet0-1
  {"description": "Uplink to Core", "enabled": true}
-- Easily generated, validated, and parsed by
-- software, without any ambiguity about meaning

This structured approach allows the same configuration change to be applied consistently and reliably across thousands of devices simultaneously through a script, rather than manually repeating the same CLI sequence device by device.

REST APIs: The Dominant Modern Approach

Most modern network devices and controllers expose a REST (Representational State Transfer) API, which uses standard HTTP methods to perform operations, discussed earlier in this series regarding HTTP as an application-layer protocol.

Common REST API operations, mapped to HTTP methods:

GET     - retrieve information (e.g., current
          interface configuration)
POST    - create a new resource
PUT     - update/replace an existing resource
DELETE  - remove a resource

Example request retrieving interface status:
GET https://device-ip/restconf/data/interfaces

Example response (simplified):
{
  "interfaces": {
    "interface": [
      {"name": "GigabitEthernet0/1", "enabled": true}
    ]
  }
}

This mirrors the CRUD (Create, Read, Update, Delete) pattern found throughout software development generally, making network automation approachable for programmers coming from other software backgrounds without needing to learn an entirely unfamiliar paradigm.

JSON: The Common Language of API Responses

JSON (JavaScript Object Notation) is the most common data format used in API requests and responses, structuring data as nested key-value pairs that are both human-readable and easily parsed by nearly every programming language.

Example JSON representing a switch interface:
{
  "interface": "GigabitEthernet1/0/1",
  "vlan": 10,
  "status": "up",
  "speed": 1000,
  "duplex": "full"
}

Key characteristics:
- Curly braces {} define an object
- Square brackets [] define a list/array
- Keys and string values are wrapped in quotes
- Nesting represents hierarchical relationships

YAML: A More Human-Readable Alternative

YAML (YAML Ain't Markup Language) represents the same kind of structured data as JSON, but using indentation rather than braces and brackets, making it noticeably easier for humans to read and write by hand — YAML is the standard format for automation tool configuration files, such as Ansible playbooks.

The same interface data represented in YAML:

interface: GigabitEthernet1/0/1
vlan: 10
status: up
speed: 1000
duplex: full

-- Indentation (spaces, never tabs) defines the
-- structure instead of explicit braces and brackets

JSON and YAML represent the exact same underlying data structures and can be programmatically converted between each other — the choice between them is largely about which format is being consumed by a particular tool, with YAML generally preferred for files humans write and edit directly, and JSON generally preferred for data exchanged between systems.

Ansible: Declarative Configuration Management

Ansible is among the most widely used network automation tools, using YAML-formatted Playbooks to describe the desired end state of a device's configuration, rather than the step-by-step commands needed to reach it.

Simplified example Ansible playbook:

- name: Configure interface description
  hosts: switches
  tasks:
    - name: Set interface description
      ios_config:
        lines:
          - description Uplink to Core
        parents: interface GigabitEthernet0/1

This Declarative approach — describing what the end state should look like rather than the exact sequence of commands to get there — is a fundamental shift in thinking compared to the imperative, step-by-step CLI configuration covered throughout this series, and Ansible (or similar tools) determines the specific commands needed on each device to reach that described state.

Controller-Based Networking: A Deeper Architectural Shift

Beyond simply automating configuration of individually managed devices, Controller-Based Networking introduces a centralized system that manages an entire fleet of devices as a single logical entity, similar in spirit to the centralized WLC architecture discussed earlier in this series regarding wireless networks, but extended to wired infrastructure as well.

Traditional model: each device individually
  configured and managed, whether via CLI or API

Controller-based model: a central controller
  (such as Cisco DNA Center or Cisco ACI) maintains
  the desired network-wide configuration and policy,
  automatically pushing appropriate configuration
  to each managed device, and continuously monitoring
  for and correcting configuration drift

This architectural shift mirrors the same underlying pattern seen throughout networking evolution: replacing distributed, individually managed intelligence with centralized management and policy, a pattern already familiar from the WLC-based wireless architecture discussed earlier in this series, now extended to the entire network fabric.

Why Automation Fluency Is Becoming a Core Networking Skill

Network automation does not replace the fundamental networking concepts covered throughout the rest of this series — understanding OSPF, VLANs, and ACLs remains essential, since automation tools ultimately configure exactly these same underlying technologies. What automation changes is how that configuration gets applied at scale: fluency with APIs, JSON/YAML data formats, and tools like Ansible has become an increasingly expected skill for network engineers working in modern, large-scale environments, complementing rather than replacing traditional CLI expertise.