Що таке JSON? Простий посібник з прикладами

JSON (JavaScript Object Notation) — це простий текстовий формат для запису структурованих даних, наприклад клієнта, замовлення чи списку товарів, у вигляді пар назв і значень. Його легко читати людям і легко створювати та розбирати програмам. Коли застосунки й сервіси обмінюються даними через вебмережу, JSON — найпоширеніший формат.

Чому JSON важливий, коли ви створюєте з ШІ

З JSON ви стикаєтеся постійно, навіть якщо ніколи не пишете код:

• API. Коли екрани вашого застосунку завантажують дані з бекенду або ваш бекенд викликає сервіс оплати, пошти чи ШІ, дані зазвичай передаються у форматі JSON. Див. що таке API.
• Файли налаштувань. Багато файлів конфігурації проєкту є JSON, наприклад package.json, де перелічено залежності JavaScript-проєкту.
• Бази даних. Postgres може зберігати JSON у стовпці (тип jsonb) для даних, які не вкладаються в охайні рядки й стовпці. Див. що таке Postgres.
• Вивід ШІ. Коли потрібно, щоб модель ШІ повернула щось, із чим може працювати програма — список тегів, витягнуті поля рахунку, — зазвичай просять JSON.
• Повідомлення про помилки та журнали. Багато помилок надходять у JSON, і їх читання — часто найшвидший спосіб дізнатися, що пішло не так.

Вміння читати JSON дає змогу перевірити, що насправді отримав ваш застосунок, помітити відсутнє поле і точно описати проблему вашому конструктору ШІ.

Повсякденна аналогія

Уявіть паперову анкету: Ім'я: ____, Телефон: ____, Розсилка: ☐ так ☐ ні. Кожен запис — це підпис і значення поруч. JSON — це така анкета, записана текстом у суворій структурі, яку комп'ютер може прочитати без здогадок. І, як в анкетах, у JSON можуть бути розділи всередині розділів (блок адреси з вулицею, містом і поштовим індексом) та списки (кілька номерів телефонів).

Як виглядає JSON

Ось одне бронювання у форматі JSON:

{
  "id": 5001,
  "customer": "Lena Park",
  "service": "Haircut",
  "startsAt": "2026-10-03T14:00:00Z",
  "price": 35.5,
  "paid": false,
  "notes": null,
  "extras": ["beard trim", "hot towel"],
  "contact": {
    "email": "lena@example.com",
    "phone": "+44 20 7946 0000"
  }
}

Як це читати:

• Фігурні дужки { } огортають об'єкт — набір пар назва/значення.
• Кожна пара має вигляд "назва": значення і відокремлюється комами.
• Квадратні дужки [ ] огортають масив — впорядкований список.
• Об'єкти й масиви можуть бути вкладені один в одного, як contact і extras.

Шість видів значень

У JSON лише шість типів значень. Саме цей короткий список — одна з причин, чому він працює всюди.

Типу дати немає. Дати записуються як рядки, зазвичай у форматі ISO 8601, як показано вище (2026-10-03T14:00:00Z, де Z означає UTC). Домовленість про цей формат запобігає цілій категорії помилок із часовими поясами.

Суворі правила (звідки беруться помилки)

JSON менш поблажливий, ніж здається. Усе нижче — недійсний JSON:

{ name: "Lena" }            ← ключ без подвійних лапок
{ 'name': 'Lena' }          ← одинарні лапки
{ "a": 1, "b": 2, }         ← кома після останнього елемента
{ "a": 1 "b": 2 }           ← пропущена кома
{ "a": 1 // comment }       ← коментарі не допускаються

Більшість помилок «Unexpected token», які ви побачите, — це одна з цих. Валідатор або форматувальник JSON покаже точний рядок.

Робочий приклад: JSON у застосунку

Клієнт бронює стрижку в застосунку салону. Ось де з'являється JSON:

1. Форма бронювання надсилає бекенду застосунку таке:

{ "service": "Haircut", "startsAt": "2026-10-03T14:00:00Z", "name": "Lena Park" }

1. Бекенд зберігає бронювання в базі даних і відповідає статусом 201 Created та таким:

{ "id": 5001, "status": "confirmed" }

1. Якщо цей час уже зайнятий, він може натомість відповісти статусом 409 Conflict і таким:

{ "error": "slot_taken", "message": "That time was just booked. Please pick another." }

Сторінка читає status або error і показує потрібне повідомлення. Якщо замість цього сторінка показала порожній екран, відкриття інструментів розробника в браузері (вкладка Network) покаже саме цей JSON — часто це найшвидша підказка, що пішло не так.

Ключові терміни

Поширені хибні уявлення

• «JSON — це JavaScript». Він походить із синтаксису JavaScript, але не прив'язаний до мови; Python, Java, C#, Go та інші читають його.
• «Числа в лапках — це нормально». "35" — це рядок, а не число. Змішування призводить до помилок, наприклад "35" + "5" стає "355". Гроші часто краще зберігати як цілі центи (3550), щоб уникнути проблем з округленням.
• «JSON безпечний, бо це просто дані». JSON може містити що завгодно, зокрема секрети. Не кладіть API-ключі в JSON, який надсилається в браузер.
• «Зберігайте все в стовпці JSON». Це зручно для гнучких додаткових полів, але дані, за якими ви шукаєте, фільтруєте чи об'єднуєте, зазвичай мають бути у звичайних стовпцях.
• «ШІ завжди повертає валідний JSON». Моделі можуть додати зайвий текст або порушити формат. Багато провайдерів пропонують режим структурованого виводу, але ваш код усе одно має перевіряти відповідь.

Що попросити у вашого конструктора ШІ

• «Покажи приклад JSON, який повертає цей endpoint.»
• «Повертай помилки у форматі JSON з кодом error і зрозумілим для людини message.»
• «Зберігай дати як рядки ISO 8601 у UTC і перетворюй на місцевий час лише на екрані.»
• «Зберігай ціни як цілі центи.»
• «Перевіряй вхідний JSON на сервері й відхиляй запити з відсутніми або неправильного типу полями.»
• «Під час виклику моделі ШІ проси JSON саме в такій формі і перевіряй його перед використанням.»

JSON у Mythex

У Mythex не потрібно писати JSON вручну: ви описуєте, що хочете, а агент пише код, який його надсилає й читає. Проте корисно його розпізнавати: коли щось ламається, вставка помилки JSON у чат дає агентові точну підказку. У рецепті бекенд REST API у документації з самого початку просять «зрозумілі помилки JSON», а рецепт інтеграція з будь-яким API розповідає про виклики зовнішніх сервісів. Для ширшої картини див. REST чи GraphQL і як налагодити застосунок, створений з ШІ.

Запитання