Що таке JSON: просте пояснення без коду

6 хв читанняОновлено

JSON простими словами: як виглядає, чим відрізняється від CSV/таблиці, де зустрічається у вебхуках і відповідях API, і які помилки роблять новачки при ручному редагуванні.

Поділитись:TelegramX

Коротка відповідь

JSON (JavaScript Object Notation) — це текстовий формат для запису структурованих даних у вигляді пар "ключ: значення", зрозумілий одночасно і людині, і програмі. У no-code автоматизації ви стикаєтесь із JSON постійно, навіть не пишучи код: саме в цьому форматі вебхук передає дані про подію, а API-сервіс повертає відповідь на запит.

Як виглядає JSON на прикладі

Уявіть, що вебхук передає дані про нове замовлення:

{
  "orderId": 1042,
  "customer": "Олена Коваль",
  "total": 850,
  "paid": true,
  "items": ["светр", "шарф"]
}

Тут одразу видно всю структуру JSON:

  • Ключ і значення розділені двокрапкою: "customer": "Олена Коваль"
  • Рядок (текст) — завжди в лапках: "Олена Коваль"
  • Число — без лапок: 850
  • Булеве значення (так/ні) — true чи false, без лапок: paid: true
  • Масив (список значень) — у квадратних дужках: ["светр", "шарф"]
  • Усе разом обгорнуто у фігурні дужки { } — це і є об'єкт

Об'єкти можуть бути вкладеними один в одного — наприклад, замість рядка "customer": "Олена Коваль" могло б бути ціле вкладене поле з окремими "name", "phone", "email".

Де JSON реально зустрічається в автоматизації

  • Тіло вебхука — коли зовнішній сервіс надсилає подію в n8n/Zapier/Make, дані завжди приходять у форматі JSON
  • Відповідь API — коли ваш воркфлоу запитує дані в сервісі (наприклад, курс валют чи погоду), відповідь теж JSON
  • Експорт воркфлоу — файл, який ви завантажуєте при експорті сценарію n8n чи Zap-а для бекапу чи шаринга на форумі, теж записаний у JSON
  • Мапінг полів у no-code редакторі — коли ви бачите в Zapier/Make/n8n список полів для перетягування в наступний крок, редактор просто "розпаковує" JSON-структуру попереднього кроку в зручний список

Саме невідповідність формату JSON — одна з типових причин помилок 400/422, з якими стикаються навіть готові воркфлоу: докладніше в статті чому Zap у Zapier не спрацьовує.

Чим JSON відрізняється від таблиці чи CSV

CSV / таблиця JSON
Структура Плоска — рядки й колонки Ієрархічна — об'єкти можуть містити інші об'єкти й масиви
Типи даних Усе — текст, немає розрізнення чисел/булевих значень Явні типи: рядок, число, булеве значення, масив, null
Пропущені значення Порожня клітинка Поле або відсутнє, або явно null
Читабельність для людини Зручно у великих обсягах (таблиця) Зручно для одного запису, незручно переглядати сотні записів підряд

Практичний наслідок: якщо дані плоскі й однорідні (список товарів з однаковими полями) — таблиця зручніша. Якщо дані мають вкладену структуру (замовлення з масивом товарів усередині) — JSON передає це природно, а таблиця вимагає штучно "розплющувати" структуру в окремі колонки чи рядки.

Поширені помилки новачків

Ручне редагування JSON без розуміння лапок і ком. Найчастіша поламка — забута кома між полями чи зайва кома після останнього поля ({"a": 1, "b": 2,} — зайва кома в кінці робить JSON недійсним у більшості парсерів). Якщо доводиться редагувати JSON вручну (наприклад, тіло запиту в HTTP-ноді), краще спершу перевірити результат у будь-якому онлайн JSON-валідаторі, перш ніж вставляти в робочий сценарій.

Плутати null з порожнім рядком. "phone": null означає "поле явно відсутнє", а "phone": "" означає "поле є, але порожнє". No-code інструменти часто по-різному обробляють ці два випадки в умовах (IF/Filter) — умова "поле не порожнє" може несподівано пропустити запис із null.

Очікувати, що JSON завжди плаский, як у першому прикладі при навчанні. Реальні відповіді API часто мають кілька рівнів вкладеності (масив об'єктів, кожен з яких має власні вкладені об'єкти) — якщо в мапінгу полів потрібне значення "не знаходиться" одразу, найчастіша причина — воно на кілька рівнів глибше, ніж очікувалось, а не помилка налаштування.

Плутати JSON зі схожим на вигляд, але іншим форматом. JavaScript-об'єкт у коді (без лапок навколо ключів: {a: 1}) виглядає майже як JSON, але формально JSON вимагає лапки навколо кожного ключа ({"a": 1}) — копіювання прикладу коду напряму як JSON-тіла запиту іноді ламається саме через цю різницю.

Часті питання

Чи потрібно вміти писати JSON, щоб користуватись n8n, Zapier чи Make?

Ні, для базових сценаріїв — ні. Редактори цих інструментів самі показують поля з JSON-відповіді як звичайний список для перетягування. Розуміння JSON стає потрібним, коли ви вручну формуєте тіло HTTP-запиту чи налагоджуєте, чому потрібне поле не підхопилось автоматично.

Чому в деяких відповідях API дані загорнуті в масив, а в інших — ні?

Залежить від того, що повертає ендпоінт: якщо запит про "один об'єкт" (наприклад, конкретне замовлення за ID) — відповідь зазвичай один об'єкт. Якщо запит про "список" (усі замовлення за сьогодні) — відповідь масив об'єктів, навіть якщо результат один-єдиний запис.

Що робити, якщо потрібне поле є в JSON, але його не видно в списку мапінгу?

Найчастіше поле вкладене на кілька рівнів глибше (об'єкт усередині об'єкта, чи елемент масиву) — no-code редактори не завжди "розпаковують" усі рівні автоматично. Подивіться сирий JSON-вивід попереднього кроку (зазвичай є кнопка на кшталт "Show raw data" чи "View output") і знайдіть точний шлях до потрібного поля.

Чим JSON відрізняється від XML, який теж іноді зустрічається в API?

Обидва — формати структурованих даних, але XML використовує теги (<name>Олена</name>), а JSON — пари ключ-значення. JSON зазвичай компактніший і легше читається, тому більшість сучасних API (і всі основні no-code інструменти) використовують саме його; XML частіше трапляється в старіших чи корпоративних системах (SOAP-сервіси, деякі банківські API).


Дата останньої перевірки актуальності: 18 серпня 2026 р.

Схожі статті