Computing Foundations for AI / Software & Data
The shared language of APIs.
Reviewed by Yuvaraj
Nearly every time two programs exchange data over a network, a browser talking to a server, your code calling an AI model, one service messaging another, they speak JSON. Short for JavaScript Object Notation, JSON is a lightweight text format for representing structured data. It became the lingua franca of the web and of AI APIs not because it is clever, but because it is boring in the best way: a human can read it, essentially every programming language can produce and consume it, and its shape maps almost perfectly onto the data structures programmers already use.
The whole of JSON is built from just six kinds of value, and that deliberate smallness is its strength. Everything you will ever see in a JSON document is one of these, nested inside the others.
| JSON type | Example | Maps to |
|---|---|---|
| string | "chat-model-large" | text |
| number | 0.7 | integer or float |
| boolean | true | true / false |
| null | null | intentional absence of a value |
| array | [1, 2, 3] | ordered list |
| object | {"role": "user"} |
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
| dictionary / map of key-value pairs |
A JSON object is a collection of key-value pairs: each key is a double-quoted string, and each value is one of the six types above. Because a value can itself be an array or an object, JSON nests freely, an object can hold an array of objects, each of which holds more arrays. This is exactly why it can describe rich, tree-shaped data that flat formats cannot.
This is the single most important idea in the lesson. A JSON document is text, a plain string of characters, not a live value your program can index into. Converting that text into an in-memory value (a dictionary, a list) is called parsing. Converting an in-memory value back into a JSON string is called serializing. In JavaScript these are JSON.parse and JSON.stringify; in Python, json.loads and json.dumps. Confusing the two is the source of countless bugs.
in-memory value → serialize → JSON text → network → parse → in-memory value
When you call a large language model over an API, both what you send and what you receive are JSON. "Structured output" or "JSON mode" features go a step further: they constrain the model to emit a response that is itself valid JSON matching a schema you specify, so your code can parse it reliably instead of scraping free-form prose.
A typical request body to a chat-style model looks like this:
{
"model": "chat-model-large",
"messages": [
{ "role": "system", "content": "You are a concise assistant." },
{ "role": "user", "content": "Explain JSON in one sentence." }
],
"temperature": 0.7
}
The top level is an object. Its model key holds a string. Its messages key holds an array, and every element of that array is itself an object with two string keys, role and content. Finally temperature is a number. A matching response reverses the flow:
{
"id": "resp_8f3c1a",
"object": "chat.completion",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "JSON is a text format for structured data."
},
"finish_reason": "stop"
}
]
}
Here id is a string, choices is an array of objects, and each choice contains a nested message object, an object inside an object inside an array. Your code parses this text, then reads the assistant's reply from the content field of that nested message.
CSV is ideal for flat spreadsheets. Two other formats round out the toolkit: YAML is a human-friendly superset often used for configuration files, and Parquet is a columnar binary format built for large analytical datasets, where compactness and fast column reads matter more than being human-readable.
Common mistakes
0.7 is a number; "0.7" is a string. They parse to different types.