In the world of network automation, how you represent data matters. XML and JSON are the two dominant formats for encoding structured data in RESTful APIs and model-driven programmability. The CCNA 200-301 exam objective 6.4 requires you to understand the differences between XML and JSON, their syntax, and their use in network automation. This knowledge is essential for any network engineer who wants to move beyond the CLI and embrace automation with tools like Ansible, Python scripts, and RESTCONF/NETCONF.
Jump to a section
Imagine you are a logistics manager coordinating international shipments. You need to send a detailed manifest of cargo to customs officials in different countries. Each country has its own preferred format: Country A uses a verbose, hierarchical XML-like form with every field clearly labeled and nested; Country B uses a compact, lightweight JSON-like form with minimal characters and a straightforward key-value structure.
For Country A (XML), your manifest looks like a formal document. Each container is wrapped in opening and closing tags: <container><id>123</id><contents><item><name>Widget</name><quantity>50</quantity></item></contents></container>. The customs officers love this because they can validate the structure against a schema, and the hierarchy is explicit. But the document is large, and typing it out is tedious.
For Country B (JSON), you write the same information in a compact style: {"container": {"id": 123, "contents": [{"name": "Widget", "quantity": 50}]}}. It’s easier to read quickly, takes up less bandwidth when transmitting, and is simpler for computers to parse. However, it lacks built-in validation rules; you need external tools to enforce structure.
Now, consider that you have to automate the submission of these manifests to hundreds of ports daily. If you choose XML, your scripts will be more complex to generate but will be self-validating. If you choose JSON, your scripts will be simpler and faster, but you must ensure data integrity elsewhere. In network automation, XML is often used with NETCONF for its strong validation and hierarchical nature, while JSON is preferred with RESTCONF for its simplicity and speed. Understanding these trade-offs helps you choose the right tool for the job.
XML (eXtensible Markup Language) and JSON (JavaScript Object Notation) are both data serialization formats used to represent structured data in a text-based, human-readable way. They are not protocols themselves but are used as payloads in protocols like HTTP (RESTCONF) or SSH (NETCONF). In network automation, they encode configuration data, operational state, and RPC (Remote Procedure Call) messages.
Why They Exist in Networking
Traditional CLI-based management is brittle: outputs are designed for human eyes, not machines. Parsing "show running-config" is error-prone and device-specific. XML and JSON provide a standardized, structured way to represent data that can be programmatically consumed. They enable model-driven automation where the data model (e.g., YANG) defines the structure, and the encoding format (XML or JSON) serializes that structure for transmission.
XML Syntax and Structure
XML uses a tree of elements, each enclosed in tags. Tags come in opening (<tagname>) and closing (</tagname>) pairs. Elements can have attributes (key-value pairs inside the opening tag) and can contain text or nested elements. A well-formed XML document must have a single root element and every opening tag must have a matching closing tag.
Example:
<interface>
<name>GigabitEthernet0/1</name>
<ip-address>192.168.1.1</ip-address>
<subnet-mask>255.255.255.0</subnet-mask>
</interface>XML is verbose because of repeated tags. It supports namespaces (xmlns) to avoid element name conflicts, which is critical in complex models like YANG. XML Schema (XSD) or Document Type Definition (DTD) can enforce structure, but these are optional.
JSON Syntax and Structure
JSON uses key-value pairs and arrays. An object is enclosed in curly braces {} with comma-separated key:value pairs. Keys must be strings in double quotes. Values can be strings, numbers, booleans, arrays ([]), or objects ({}). JSON is less verbose than XML because it doesn’t require closing tags.
Example:
{
"interface": {
"name": "GigabitEthernet0/1",
"ip-address": "192.168.1.1",
"subnet-mask": "255.255.255.0"
}
}JSON is native to JavaScript, making it the default for web APIs. It is generally easier for humans to read and for machines to parse due to its simplicity.
Comparing XML and JSON for Network Automation
Verbosity: XML typically uses more characters due to repeated tags. JSON is more compact, reducing bandwidth usage.
Data Types: JSON natively supports strings, numbers, booleans, null, arrays, and objects. XML treats everything as text; data types must be inferred or defined in a schema.
Metadata: XML supports attributes and namespaces, which can carry metadata inline. JSON has no native attribute concept; metadata must be added as extra keys.
Schema Support: XML has built-in schema validation (XSD). JSON can use JSON Schema, but it is an external standard.
Parsing Speed: JSON parsers are generally faster because the structure is simpler. XML parsing requires more overhead.
How They Are Used in Network Automation
In the CCNA scope, the primary use cases are with NETCONF and RESTCONF protocols. NETCONF traditionally uses XML as its payload encoding. RESTCONF supports both XML and JSON, with JSON being more common.
NETCONF: Uses XML for all messages (hello, RPC, data). The YANG model defines the XML structure. Example NETCONF <get> request:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
</filter>
</get>
</rpc>RESTCONF: Uses HTTP methods (GET, POST, PUT, PATCH, DELETE) and can accept both XML and JSON. The API endpoint typically specifies the format via Accept header or file extension (.json, .xml). Example RESTCONF GET using JSON:
GET /restconf/data/ietf-interfaces:interfaces
Accept: application/yang-data+jsonResponse:
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "GigabitEthernet0/1",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true
}
]
}
}IOS CLI Verification Commands
On a Cisco IOS XE device, you can verify NETCONF and RESTCONF configuration and see encoding preferences.
Check NETCONF status:
Router# show netconf-yang sessions
RPC: NETCONF
Session ID: 1
Transport: SSH
Username: admin
Source Host: 10.1.1.1
Session Start: 2025-03-20T10:00:00Check RESTCONF status:
Router# show platform software yang-management process
Confd status: Running
Ncs status: RunningTo see the YANG models loaded:
Router# show netconf-yang schemasInteraction with Related Protocols
XML and JSON are data encoding formats, not transport protocols. They ride on top of: - NETCONF: Uses SSH as transport, XML as encoding. - RESTCONF: Uses HTTP/HTTPS as transport, can use XML or JSON. - gRPC: Uses HTTP/2, typically uses Protocol Buffers (not JSON/XML), but can be adapted.
In the CCNA exam, focus on the distinction that NETCONF mandates XML, while RESTCONF supports both but JSON is preferred. Understand the syntax differences: XML uses tags, JSON uses curly braces and colons.
Exam Relevance
The CCNA 200-301 exam objective 6.4 states: "Compare XML and JSON." You need to know:
Syntax differences
Use cases in network automation (NETCONF vs RESTCONF)
Advantages and disadvantages of each
How to identify which format is being used in a given scenario
Identify the Data Format
Given a snippet of data, determine whether it is XML or JSON. Look for key indicators: XML uses angle brackets (< >) for tags; JSON uses curly braces ({ }) for objects and square brackets ([ ]) for arrays. XML often has a declaration (<?xml version="1.0"?>), while JSON does not. XML elements have both opening and closing tags; JSON has key-value pairs separated by colons.
Analyze the Structure
Examine the hierarchy. In XML, nesting is shown by tags inside tags. In JSON, nesting is shown by objects inside objects or arrays. For example, an interface with name and IP address in XML: <interface><name>G0/1</name><ip>10.1.1.1</ip></interface>. In JSON: {"interface": {"name": "G0/1", "ip": "10.1.1.1"}}.
Check for Attributes vs. Keys
XML allows attributes within the opening tag, e.g., <interface name="G0/1">. JSON does not have attributes; metadata must be represented as a separate key, e.g., {"interface": {"name": "G0/1"}}. This is a key differentiator on the exam.
Evaluate Verbosity
Compare the length of equivalent data in both formats. XML is generally more verbose because each element requires an opening and closing tag. JSON is more concise. For example, a list of two interfaces: XML uses many repeated tags; JSON uses array brackets and fewer characters.
Determine the Protocol Context
Identify which protocol is being used. If the scenario mentions NETCONF, the encoding is always XML. If it mentions RESTCONF, both XML and JSON are possible, but JSON is more common. If the scenario involves a web API (e.g., with HTTP), JSON is typical. This helps narrow down the expected format.
Apply to Automation Scripts
Consider how a script would parse the data. JSON can be directly parsed into native objects in many programming languages (e.g., Python's json module). XML parsing requires more code (e.g., using xml.etree.ElementTree). For simple data exchange, JSON is easier; for complex hierarchical data with validation needs, XML may be preferred.
In enterprise networks, the choice between XML and JSON often depends on the existing automation toolchain and the protocols in use.
Scenario 1: Migrating from CLI to NETCONF A large enterprise with thousands of Cisco IOS XE devices wants to automate configuration backups. They decide to use NETCONF because it provides transactional, validated configuration changes. The team writes Python scripts using the ncclient library, which sends and receives XML payloads. They must ensure all engineers understand XML syntax to build correct filter and edit-config operations. The verbosity of XML is a minor drawback compared to the benefit of schema validation. A misconfigured XML payload (e.g., missing namespace) results in an error from the device, preventing accidental misconfigurations.
Scenario 2: RESTCONF for Cloud Integration A service provider uses RESTCONF to integrate their network devices with a cloud-based orchestration platform. The platform's API consumes JSON natively. They configure RESTCONF on their routers to accept JSON payloads. The team uses Python requests library to send HTTP requests with JSON data. The compact nature of JSON reduces bandwidth and parsing time. However, they must implement external validation to ensure data integrity because JSON lacks built-in schema enforcement. They use JSON Schema to validate payloads before sending.
Scenario 3: Ansible Playbooks Ansible, a popular automation tool, supports both XML and JSON. When using the iosxr_netconf module, Ansible sends XML over NETCONF. When using the iosxr_restconf module, it sends JSON over RESTCONF. A network engineer writing Ansible playbooks must understand the encoding format to interpret debug output and troubleshoot failures. For example, a typo in a JSON key (missing double quotes) causes a parse error, while in XML a missing closing tag causes a well-formedness error.
Scale and Performance In large networks, the difference in verbosity becomes significant. A full device configuration in XML can be 30-50% larger than the same data in JSON. For thousands of devices, this impacts storage and bandwidth. However, XML's namespace support is crucial when merging models from different vendors. Many automation platforms use XML internally for its robustness but expose JSON to end-users for simplicity.
Misconfiguration Consequences If you send XML to a RESTCONF endpoint expecting JSON, the server returns a 400 Bad Request. If you send JSON to a NETCONF session, the session will likely terminate with an error. Understanding the correct encoding for the protocol is critical.
The CCNA 200-301 exam objective 6.4 specifically asks you to "Compare XML and JSON." This is a foundational knowledge objective, typically tested with multiple-choice questions that present a snippet of data and ask you to identify the format, or ask about characteristics.
Common Wrong Answers and Why Candidates Choose Them
"JSON uses tags like XML" – This is false. JSON uses curly braces and colons, not angle brackets. Candidates confuse the two because both are text-based.
"XML is more human-readable than JSON" – This is subjective, but generally JSON is considered more readable due to less clutter. Candidates may think XML's descriptive tags are clearer.
"NETCONF uses JSON" – False. NETCONF mandates XML. Candidates may confuse NETCONF with RESTCONF.
"JSON supports attributes" – False. XML supports attributes within tags; JSON does not have a native attribute concept.
Specific Values and Command Outputs - Know that NETCONF uses SSH port 830 and XML encoding. - RESTCONF uses HTTPS port 443 and can use XML or JSON. - The YANG model defines the data structure; XML and JSON are just encodings. - Example XML snippet: <name>GigabitEthernet0/1</name> - Example JSON snippet: "name": "GigabitEthernet0/1"
Decision Rule for Scenario Questions If a question describes a protocol, use the encoding associated with it:
NETCONF → XML
RESTCONF → JSON (or XML, but JSON is more common)
gRPC → Protocol Buffers (not on CCNA)
SNMP → ASN.1 (not on CCNA)
If a question shows a data format, identify it by syntax:
Angle brackets → XML
Curly braces and colons → JSON
Elimination Strategy When asked to compare, eliminate options that claim JSON is more verbose (false), that XML is not hierarchical (false), or that NETCONF can use JSON (false). Remember that both can represent the same data, but the choice depends on the protocol and use case.
XML uses tags (< >) and requires closing tags; JSON uses curly braces ({ }) and key-value pairs.
NETCONF always uses XML encoding; RESTCONF supports both XML and JSON, with JSON being more common.
JSON is more compact and faster to parse; XML supports attributes and namespaces.
Both XML and JSON can represent the same data structures derived from YANG models.
XML has built-in schema validation (XSD); JSON uses external JSON Schema.
On the CCNA exam, be able to identify a format from a snippet and know which protocol uses which encoding.
RESTCONF uses HTTP methods (GET, POST, PUT, PATCH, DELETE) and can return data in JSON or XML based on the Accept header.
These come up on the exam all the time. Here's how to tell them apart.
XML
Uses tags with angle brackets
Supports attributes within tags
More verbose (more characters)
Built-in schema validation (XSD)
Requires closing tags for every element
Supports namespaces for element disambiguation
JSON
Uses curly braces and colons
No native attribute support; uses nested objects
More compact (fewer characters)
No built-in validation; uses external JSON Schema
No closing tags; uses braces and brackets
No namespace support; uses unique key names
Mistake
JSON is a programming language.
Correct
JSON is a data interchange format, not a programming language. It is language-independent but derived from JavaScript.
Candidates see 'JavaScript' in the name and assume it's related to scripting.
Mistake
XML is outdated and no longer used in networking.
Correct
XML is still widely used, especially with NETCONF and in legacy systems. It is not outdated.
JSON's popularity in web development leads some to think XML is obsolete.
Mistake
RESTCONF can only use JSON.
Correct
RESTCONF supports both XML and JSON. The client specifies the desired format via the Accept header.
Many REST APIs use JSON, but RESTCONF is flexible.
Mistake
XML and JSON are protocols.
Correct
They are data serialization formats, not protocols. They are used as payloads within protocols like HTTP or SSH.
Candidates often confuse the format with the transport method.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, standard NETCONF (RFC 6241) mandates XML as the data encoding format. However, some implementations may extend NETCONF to support other encodings, but this is not standard. For CCNA, remember that NETCONF uses XML.
JSON natively supports strings, numbers, booleans, null, arrays, and objects. XML treats everything as text; data types must be inferred or defined in a schema (XSD). This makes JSON easier to work with in programming languages that automatically parse these types.
JSON is more compact, easier to read, and faster to parse. It maps directly to data structures in most programming languages. XML is more verbose and requires more processing overhead. For web APIs, JSON is the de facto standard.
If you are using NETCONF, you must use XML. If you are using RESTCONF, you can choose either; JSON is simpler and more common. Consider factors like existing tooling, bandwidth constraints, and need for schema validation. XML is better for complex hierarchical data with strict validation requirements.
YANG is a data modeling language used to define the structure of configuration and state data. It is protocol-independent. When data is serialized for transmission, YANG defines the structure that XML or JSON must follow. For example, a YANG module defines a container 'interface' with leaf 'name'; in XML it becomes <interface><name>, in JSON it becomes "interface": {"name":}.
Yes, many tools and libraries can convert between XML and JSON. However, the conversion may not be perfect because XML has features like attributes and namespaces that have no direct JSON equivalent. You may need to define conversion rules. In network automation, it's better to use the native format for the protocol.
Attributes are key-value pairs placed inside an XML opening tag, e.g., <interface name="G0/1">. JSON has no direct equivalent; you would represent the same data as a key inside the object: {"interface": {"name": "G0/1"}}. Attributes are useful for metadata that modifies the element, such as an ID or type.
You've just covered XML vs JSON in Network Automation — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?