What You'll Learn
- The structural differences between JSON and XML
- Why JSON became the default for new APIs
- Where XML is still used (and why)
- How to convert between the two when needed
Why This Matters
Most new APIs use JSON, but XML is still common in enterprise software, banking, SOAP services, and some legacy systems. If you work in those environments, you will meet XML. Knowing the trade-offs helps you understand why APIs chose one over the other.
Side-by-Side: The Same Data in Both Formats
A user record in JSON:
{
"id": 123,
"name": "Anita",
"email": "anita@example.com",
"roles": ["admin", "editor"]
}
The same data in XML:
<user>
<id>123</id>
<name>Anita</name>
<email>anita@example.com</email>
<roles>
<role>admin</role>
<role>editor</role>
</roles>
</user>
Key Differences
| Aspect | JSON | XML |
|---|---|---|
| Syntax | Key-value pairs | Tags with attributes and content |
| Size | Compact | Verbose (closing tags duplicate names) |
| Types | String, number, boolean, null, array, object | Everything is text; types must be inferred |
| Arrays | Native [1, 2, 3] | Repeated elements: <item>1</item><item>2</item> |
| Attributes | None — everything is a key | Tags can have attributes: <user id="123"> |
| Comments | Not allowed | Allowed: <!-- comment --> |
| Parsing speed | Fast (most languages have native parsers) | Slower (XML parsers are heavier) |
| Human readable | Yes, especially when pretty-printed | Yes, but more verbose |
| Schema | JSON Schema (separate) | XSD (built into XML ecosystem) |
Why JSON Won for APIs
- Smaller payloads. JSON uses about 30% fewer bytes than XML for the same data. That matters at scale.
- Native types. JSON knows numbers, booleans, and null. XML treats everything as text, so every value needs parsing.
- Simpler parsing. JSON maps directly to native data structures in every language (objects, arrays). XML requires a DOM parser.
- JavaScript alignment. Web browsers speak JSON natively. No conversion needed.
- Less ceremony. No namespaces, no DTDs, no schema declarations to ship with every payload.
Where XML Still Survives
1. SOAP APIs
SOAP (Simple Object Access Protocol) is a formal protocol that uses XML for both the envelope and the body. Common in enterprise software, banking, and payment gateways (e.g., many bank-to-bank transfers still use SOAP).
2. Microsoft Office documents
.docx, .xlsx, .pptx files are actually ZIP archives of XML files. The format is called Office Open XML.
3. SVG images
SVG (Scalable Vector Graphics) is XML. Every circle, path, and text element is an XML tag.
4. RSS and Atom feeds
Both are XML-based. Still used by podcast feeds and many news sites.
5. Configuration in enterprise software
Java's pom.xml (Maven), Spring configuration, and many enterprise tools use XML for config.
JSON Strengths (When to Choose JSON)
- Building a new REST API
- Web and mobile apps talking to a backend
- Microservices communication
- Configuration files (package.json, tsconfig.json)
- NoSQL databases (MongoDB stores JSON-like documents)
XML Strengths (When XML Might Still Be the Right Choice)
- You need mixed content (text with embedded markup, like a document)
- You need attributes vs elements distinction
- You work in a domain that mandates XML (banking, healthcare, government)
- You need strict schema validation with XSD
- You need namespaces to combine vocabularies from different sources
Converting Between JSON and XML
There is no perfect 1:1 mapping — XML has attributes, JSON does not. But for simple data, you can convert:
JSON to XML (Node.js)
const { json2xml } = require('xml-js');
const xml = json2xml({user: {id: 123, name: "Anita"}}, {compact: true});
// <user><id>123</id><name>Anita</name></user>
XML to JSON (Python)
import xmltodict, json
with open("data.xml") as f:
data = xmltodict.parse(f.read())
print(json.dumps(data, indent=2))
Common Mistakes
- Assuming XML is dead. It is not. Many enterprises still run XML-based systems, and SOAP APIs still power critical infrastructure.
- Trying to use XML for new web APIs. JSON is the standard. Use XML only when an existing system requires it.
- Confusing JSON Schema with XSD. Both validate data, but they use different syntax and capabilities. JSON Schema cannot express everything XSD can (e.g., attribute vs element distinction).
- Parsing XML with regex. XML has edge cases (namespaces, CDATA, entities) that regex cannot handle. Use a real XML parser.
Practical Exercise (5 minutes)
Convert this JSON to XML by hand:
{"book": {"title": "APIs 101", "author": "Anita", "year": 2026}}
Answer:
<book>
<title>APIs 101</title>
<author>Anita</author>
<year>2026</year>
</book>
Notice how XML duplicates the tag name in the closing tag — that is the source of most of its verbosity.
Mini Challenge
Find a public SOAP API (search "free SOAP API"). Most are weather or currency conversion services. Try calling one with cURL — you'll see the XML envelope in the request and response. Compare the experience to calling a JSON API. The contrast explains why JSON won.
Key Takeaways
- JSON is compact and type-aware; XML is verbose and treats everything as text.
- JSON won for new APIs because it is smaller, faster, and aligns with JavaScript.
- XML still survives in SOAP, Office documents, SVG, RSS, and enterprise config.
- Use JSON for new work. Use XML when an existing system requires it.
- There is no perfect 1:1 conversion between the two — XML's attributes have no direct JSON equivalent.
Previously: Lessons 11–14 covered JSON fundamentals, nesting, reading, and validation.
Today: You saw why JSON replaced XML and where XML still survives.
Next: Module 2 is complete. Module 3 begins with lesson 16 — What Is REST?, where you'll learn the architectural principles behind most modern APIs.
FAQ
Is YAML a replacement for JSON?
YAML is a superset of JSON that is more human-readable (no quotes, no braces, indentation-based). It is popular for configuration files (Docker Compose, Kubernetes). But it is slower to parse and has edge cases (the "Norway problem" — NO parses as boolean false). Use YAML for config; use JSON for APIs.
Can an API support both JSON and XML?
Yes, via content negotiation. The client sends Accept: application/xml or Accept: application/json, and the server returns the requested format. Older enterprise APIs often support both. New APIs usually support only JSON.
Comments
Comments
Post a Comment