The format almost every API speaks: labelled values wrapped in braces, readable by both machines and people.
Why it exists
The frontend and backend are often written in different languages on different machines, yet they must exchange structured data like an order with its items and prices. Sending raw memory or ad hoc text would force everyone to reinvent parsing. JSON exists as a simple, universal text format that both sides read and write the same way, which is why almost every API speaks it.
How it actually works
When the backend answers, it does not send a page, it sends data. JSON is the near-universal way to write that data: a product becomes { "name": "Kacchi", "price": 649, "in_stock": true }. Names on the left, values on the right.
Both sides agree on this format, so the frontend knows exactly how to read price or in_stock out of the response and put it on screen.
A senior PM walks you through it
A junior PM, stuck
I spec'd "show how many portions are left" on the menu screen. The backend dev replied with a block of code and asked "which field do you mean?" and I honestly cannot read it. I don't want to guess and look stupid.
That block of code is JSON, and it is the actual reply the store's server sends when the app asks for the menu. You can learn to read it in five minutes, and once you can, you will answer his question yourself. The real response has all twelve items; I cut it to two so we can read every line. Look at it first, then walk the numbered steps with me.
GET /api/products response, trimmed to 2 of 12 items
Response body
1{
2"count":12,
3"products":[
4{
5"id":"p_1042",
6"name":"Kacchi Biryani (Family Pack)",
7"price":649,
8"in_stock":true
9},
10{
11"id":"p_1046",
12"name":"Ilish Bhaji Thali",
13"price":360,
14"in_stock":false
15}
16]
17}
Click a step to see the lines it points at.
Mistakes I've seen
Guessing instead of asking for a sample. The five minutes it takes to read the real response saves a sprint of building against fields that do not exist.
Assuming the on-screen label exists in the data. You will search the JSON for "Sold Out" and find nothing; the screen text is the frontend's translation of a value like in_stock: false.
Reading 649 as display-ready. It is a bare number: no currency sign, no commas. Formatting is the frontend's job, so a wrong-currency bug and a wrong-price bug are different tickets.
Treating a missing field and an empty field as the same bug. "price": null means the field exists with no value; no price line at all means the backend never sends it. Devs will fix those in different places.
Writing sample JSON in a spec with a trailing comma after the last field. It looks harmless, but it is invalid JSON and the dev's tools will reject the paste.
Reply to him with: "There is no portion count in the response, in_stock only says true or false. If we want 'only 3 left' on the menu, backend needs to add a field like portions_left, is that a small change?" You read the data, named the gap, and asked a precise question. That is the whole skill.
Where a PM meets this
When you write a spec saying "show price and stock," those field names are what actually travel in the JSON. Reading a sample response tells you exactly what data exists.
"Is that field in the response?" is a real question; if the data isn't in the JSON, the frontend cannot show it without backend work.
Hear it in a meeting
"The stock field isn't in the response yet, backend needs to add it."