Mental model
Every automation tool, API and config file needs to represent structured data: an interface has a name, an IP, a subnet, maybe a list of VLANs. The data is nested (interfaces inside devices, VLANs inside interfaces).
Three formats dominate network automation:
- JSON (JavaScript Object Notation): what REST APIs return. Machine-friendly, strict, compact. Hard for humans to write by hand but easy to parse.
- YAML (YAML Ain’t Markup Language): what humans write. Ansible playbooks, Docker Compose, GitHub Actions, Kubernetes manifests. Clean, indented, allows comments.
- XML (eXtensible Markup Language): what NETCONF and SOAP speak. Verbose with opening/closing tags, but mature and widely supported in enterprise and vendor APIs.
The exam objective (CCNAAUTO 200-901 1.1 and 1.2) is to compare the three and know how to parse them in Python.
Same data, three formats
A VLAN definition for one switch.
JSON
{
"device": "sw-core-1",
"vlans": [
{ "id": 10, "name": "data" },
{ "id": 20, "name": "voice" }
]
}
YAML
device: sw-core-1
vlans:
- id: 10
name: data
- id: 20
name: voice
XML
<device>
<name>sw-core-1</name>
<vlans>
<vlan>
<id>10</id>
<name>data</name>
</vlan>
<vlan>
<id>20</id>
<name>voice</name>
</vlan>
</vlans>
</device>
All three say the exact same thing. Byte counts: JSON ~120, YAML ~75, XML ~210.
When to use each
| Format | Use it when | Avoid it when |
|---|---|---|
| JSON | Calling a REST API; storing config in a file your code reads; most new tools | Humans need to edit it often (no comments, quotes everywhere) |
| YAML | Writing an Ansible playbook, Docker Compose, Kubernetes manifest, GitHub Actions workflow | Precision matters (YAML’s whitespace rules bite; : yes becomes boolean true) |
| XML | Talking to a NETCONF-capable Cisco device, or any older enterprise system | You have a choice (verbose, slower to type and read) |
JSON strict rules
- Keys and strings must use double quotes (
"), not single quotes. - No trailing commas.
[1, 2, 3,]is invalid JSON. - No comments. If you need to annotate, use a side file or a JSON5 extension (non-standard).
- Numbers, booleans and
nullare not quoted.
YAML gotchas
- Indentation is significant. Spaces only (no tabs). Pick 2 spaces or 4, be consistent.
yes,no,on,offare booleans in YAML 1.1. Quote them ("yes") if you mean the string.- A line starting with
-is a list item. Indent the children.
XML facts
- Every opening tag needs a closing tag (
<vlan>+</vlan>) or a self-closing one (<vlan />). - Attributes vs child elements: both are valid; vendor APIs pick a style and you follow it.
Comparison table
| JSON | YAML | XML | |
|---|---|---|---|
| Readability for humans | Medium | High | Low |
| Comments supported | No | Yes (#) | Yes (<!-- -->) |
| Dominant use in automation | REST APIs | Ansible / IaC configs | NETCONF |
| Whitespace sensitive | No | Yes | No |
| Byte size (same data) | Small | Smallest | Largest |
| Native in Python stdlib | Yes (json) | No (install PyYAML) | Yes (xml.etree) |
Parsing in Python
JSON (built-in):
import json
data = json.loads(json_string)
print(data["device"])
YAML (install first: pip install PyYAML):
import yaml
data = yaml.safe_load(yaml_string)
print(data["device"])
XML (built-in):
import xml.etree.ElementTree as ET
root = ET.fromstring(xml_string)
print(root.find("name").text)
Each returns a Python data structure (dict for JSON/YAML, Element tree for XML) that you can walk and mutate. See the deeper topic: parsing JSON and YAML in Python.
Parse JSON and YAML in the Python REPL
11 scripted steps. Launch Python, import json and yaml, parse a VLAN definition, pull out a field, pretty-print it. Each step is a real Python line.
Zero install. No network. Learn by typing.
Open the lab →The #1 mistake
Picking JSON for a human-edited config file. You will add a trailing comma, forget a quote, or want to leave a comment, and the parser dies with an unhelpful error. For things people edit by hand, use YAML. For things machines produce and consume, use JSON.
Second most common: tabs vs spaces in YAML. Pick spaces, configure your editor to insert spaces when you press Tab, and move on with your life.
FAQ
Which format does Cisco Catalyst Center use? JSON for its REST API. Same for Meraki Dashboard API, Webex API and most modern Cisco APIs.
Which format do Ansible playbooks use? YAML.
Which format does NETCONF use? XML wrapped in a NETCONF envelope (also XML). The Python ncclient library handles the envelope for you; you work with the inner data.
Is JSON a subset of YAML? YAML 1.2 is a superset of JSON: every valid JSON document is also valid YAML. The reverse is not true. In practice, you can paste JSON into a YAML parser and it works.
What about TOML? TOML (used by pyproject.toml, Rust’s Cargo.toml) is a fourth popular format, but it is not on the 200-901 exam blueprint and does not appear in Cisco APIs or Ansible. Learn it if you touch Python packaging.
What about Protocol Buffers / gRPC? Protobuf is binary and used by gRPC (which gNMI uses for streaming telemetry). Not covered by 200-901 but it is on the periphery. See the gNMI telemetry topic in the CCNA library.