JSONata: преобразование JSON — 8 практических примеров и мастерская

JSONata на практике: преобразуем ответы API, собираем отчёты и готовим данные для интерфейса. Восемь работающих задач, редактор прямо на странице, Node.js-примеры и исходники.

Что такое JSONata и какую проблему она решает

Внешний API прислал большой объект: внутри заказы, контакты, позиции, статусы и служебные поля. Вашему интерфейсу нужны только номер, название клиента и сумма. Для отчёта требуются итоги по городам, а для другой системы — объект с совсем другими именами ключей. JSONata позволяет описать такие преобразования коротким выражением и получить новый JSON, не изменяя исходный документ.

Это язык запросов и преобразования данных с реализацией на JavaScript. Его можно использовать в браузере и в Node.js. Вы выбираете нужные части документа, фильтруете записи, вычисляете значения, группируете массивы и собираете выходной объект. Выражение становится отдельным правилом, которое удобно хранить рядом с тестовыми входными данными и проверять независимо от интерфейса.

В статье используем JSONata 2.2.2 и собственный набор заявок вымышленной сервисной компании. На странице работает настоящая библиотека: можно изменить данные, выполнить выражение и скачать результат. В архиве находятся восемь законченных преобразований, интерфейс мастерской, Node.js-утилита, тесты и инструкции запуска. Начать можно сразу в браузере, а затем перенести конкретное правило в свой проект.

Где применять: интеграции, отчёты и интерфейсы

Первый сценарий — адаптер между двумя системами. CRM называет поле customer.display_name, а личный кабинет ожидает clientName. Вместо изменения всех компонентов интерфейса удобно преобразовать ответ в одном месте. Если контракт внешней системы поменяется, вы обновите адаптер и его тестовые примеры, сохранив привычный формат для остального приложения.

Второй сценарий — подготовка данных для таблиц и графиков. API может возвращать отдельные операции, а экрану нужна сумма по менеджерам или количество заявок по статусам. JSONata помогает выразить такую сводку. Она не рисует график, но выдаёт структуру, которую можно передать библиотеке визуализации. При этом решение о том, какие операции включать в показатель, остаётся частью вашей бизнес-логики.

Третий сценарий — импорт и выгрузка. Перед загрузкой контактов можно убрать лишние пробелы, привести email к нижнему регистру, переименовать поля и сохранить идентификатор источника. Перед созданием CSV или Excel — развернуть вложенные позиции в строки. Саму запись файла, проверку доступа, доставку вебхука и повтор при сетевой ошибке выполняет окружающий код.

Когда удобнее обычный JavaScript, SQL или схема данных

Для одного простого map подключать отдельный язык часто избыточно. Если команда уверенно читает JavaScript, преобразование короткое и редко меняется, обычные filter, map и reduce будут понятным выбором. JSONata особенно интересна там, где правил много, их хочется хранить отдельно от кода приложения или редактировать через ограниченный конструктор.

SQL лучше подходит для фильтрации большого набора на стороне базы. Не стоит загружать миллион строк в Node.js только ради последующей группировки, если база может вернуть готовую сводку. JSONata работает с уже полученным JSON и не заменяет запросы к хранилищу, индексы, пагинацию и контроль объёма ответа. В мастерской всего шесть заказов, поэтому результат легко проверить глазами.

Проверка схемы — отдельная задача. Преобразование может убрать неизвестные поля, но это ещё не доказывает корректность оставшихся значений. Например, отрицательная сумма останется числом, хотя нарушит правило вашего сервиса. После адаптации обычно полезно проверить выходной контракт валидатором, а до неё — убедиться, что вход относится к ожидаемому типу события. Так ошибка не превращается в тихо испорченный отчёт.

const rows = data.orders
  .filter(order => order.status === "paid")
  .map(order => ({id: order.id, amount: order.total}));

Мини-мастерская: измените данные и проверьте результат

Выберите одну из восьми задач. В левом редакторе находятся исходные данные, в правом — выражение. После изменения нажмите «Выполнить»: результат появится ниже. Для первой задачи работают параметры статуса и минимальной суммы, для восьмой — количество строк рейтинга. Подписи у параметров показывают, на какие примеры они влияют.

Начните с проверки, результат которой легко предсказать. В первой задаче выберите оплаченные заказы и минимум 20000. В исходных данных этому условию соответствует только R-103. Затем увеличьте минимум до 999999: должен получиться пустой массив. Такой опыт показывает не только успешный случай, но и поведение при отсутствии совпадений.

Кнопка «Показать ошибку» намеренно вставляет незавершённое выражение. Мастерская покажет сообщение, а предыдущий результат станет недоступен для копирования и скачивания. «Сбросить пример» вернёт исходные данные и правило выбранной задачи; общие числовые параметры сохраняются. Изменения не записываются на сервер. После обновления страницы загружается учебный набор.

Что входит в исходники и как устроен запуск

В архиве есть готовая папка public, исходные модули src, локальные копии JSONata и Bootstrap, восемь файлов выражений, один JSON с данными и автоматические тесты. Файл package-lock.json закрепляет набор зависимостей. Это позволяет восстановить тот же проект командой npm ci и сравнить своё изменение с исходным поведением.

Скрипт сборки не прячет пример за большим приложением. Он копирует исходные модули, библиотеку и стили в public, а также сохраняет читаемые исходники в public/source. Ссылки в мастерской открывают именно эти файлы. Если вы поправили src/scenes.js, выполните сборку, иначе браузер продолжит использовать предыдущую копию выражений.

Для разработки нужен Node.js 22 или новее; наши команды проверяются с Node.js 24. Готовую public можно разместить на обычном веб-сервере. Открытие index.html двойным щелчком через file:// не подходит: модульные скрипты и Worker должны загружаться по HTTP. Локальный сервер проекта слушает только адрес 127.0.0.1 и не публикует мастерскую в интернет.

npm ci --ignore-scripts
npm run build
npm test
npm start

Как читать путь, фильтр и объект результата

Выражение orders выбирает массив заказов. Продолжение orders.customer проходит по его элементам и извлекает названия клиентов. Квадратные скобки после пути ограничивают выборку, например по статусу. Фигурные скобки позволяют собрать новый объект с нужными именами полей. Точка перед конструктором объекта означает, что объект создаётся для каждого элемента выбранного контекста.

Важная особенность — текущий контекст. Внутри обработки заказа имя total относится к этому заказу, а после перехода в items — уже к товарной позиции. Если нужно сохранить значение родителя, его удобно записать в переменную до перехода. В пятом примере мы так сохраняем номер заказа и добавляем его к каждой строке позиции.

Не учите синтаксис только по внешнему сходству с JavaScript. Знак равенства в условии JSONata — одинарный, конкатенация строк использует &, а присваивание переменной записывается через :=. Ошибки здесь нормальны на первых экспериментах. Держите рядом короткий набор данных и проверяйте каждый шаг отдельно: путь, затем условие, затем выходную структуру.

[orders[status="paid"].{"id": id, "client": customer}]

Пример 1: очередь заявок с параметрами

Менеджеру нужен список оплаченных заявок выше заданной суммы. В мастерской это первый сценарий. Статус и порог передаются как bindings: $status и $minimum. Само выражение остаётся постоянным. Такой подход удобен для формы фильтра — пользователь меняет значения, а приложение не собирает строку выражения из кусочков пользовательского ввода.

На нашем наборе при статусе paid и минимуме 10000 получаются три заказа. При минимуме 20000 остаётся один. Внешние квадратные скобки гарантируют массив результата в обоих случаях и при отсутствии совпадений. Компонент таблицы может одинаково обработать rows.length, не разбирая отдельно объект, массив и undefined.

В реальном интерфейсе следует также проверить тип порога, разрешённые статусы и допустимые пределы. Мастерская отклоняет отрицательную или нечисловую сумму. Если фильтр выполняется на сервере, ограничения нельзя оставлять только в HTML-атрибутах: запрос можно отправить без вашего интерфейса. Передавайте параметры отдельно, проверяйте их серверным кодом и сохраняйте общий контракт результата.

[orders[status = $status and total >= $minimum].{
  "id": id, "client": customer, "amount": total
}]

Пример 2: карточки для API и стабильные имена полей

Во второй задаче каждый заказ превращается в карточку с key, label, amount и isPaid. Это типичный слой между внешним ответом и визуальным компонентом. Компоненту не нужно знать, как устроен исходный документ или где лежит название клиента. Он получает заранее согласованные поля и сосредотачивается на отображении.

Попробуйте добавить в выходной объект отдельное поле city. Затем измените подпись: оставьте только клиента или добавьте номер заказа. Исходный JSON не меняется, а новый результат соответствует выбранному представлению. Один документ можно преобразовать несколькими правилами для разных экранов, если это оправдано задачей.

Стабильность ключа важнее его красивого вида. Номер R-101 в примере используется как идентификатор, название клиента — как подпись. Не стоит подменять ключ индексом строки, если порядок может меняться. При подключении к реальной системе отдельно решите, как обрабатывать отсутствующий идентификатор, дубликаты и удалённые сущности: преобразование само не выберет правильную стратегию.

[orders.{"key": id, "label": customer & " · " & city,
  "amount": total, "isPaid": status = "paid"}]

Пример 3: показатели оплаченных продаж

Для панели руководителя соберём количество оплаченных заказов, их сумму и среднее значение. В нашем наборе это три заказа, 57000 общей суммы и 19000 среднего. Новые и отменённые заявки не попадают в показатель. Это условие явно записано в выражении, поэтому его можно обсудить с тем, кто будет пользоваться отчётом.

Измените total у R-103 с 24000 на 30000 и выполните правило. Сумма станет 63000, среднее — 21000. Затем верните данные кнопкой сброса. Такой маленький контрольный расчёт полезен при переносе в настоящий dashboard: он показывает, что именно считается и реагирует ли результат на изменение входа.

Для пустого периода нужно заранее выбрать поведение. Сумма, среднее и количество имеют разный смысл при отсутствии операций. Нельзя автоматически считать неизвестное среднее нулевой продажей. В production-контракте можно вернуть null и подписать карточку «Нет данных за период». Мастерская показывает базовое выражение, а правило для пустого набора вы добавляете согласно своему контракту.

($paid := orders[status="paid"]; {
  "count": $count($paid),
  "revenue": $sum($paid.total),
  "average": $round($average($paid.total), 2)
})

Пример 4: группировка по городам

Отдельные заявки превращаются в объект, где ключами выступают города, а значениями — количество и общая сумма. Из расчёта исключены отменённые заявки. Для Казани в учебных данных остаются два заказа на 24000. Для Тулы учитывается только новый заказ на 6000, потому что вторая тульская запись отменена.

Группировка полезна для региональной сводки, распределения нагрузки и подготовки серий графика. Важно понимать, что город здесь — уже нормализованная строка. Если во входе одновременно присутствуют «Москва», «москва» и «Москва » с пробелом, получатся разные ключи. Правила нормализации справочника нужно определить до группировки.

Попробуйте изменить город одного заказа и посмотрите, как перемещается его сумма. Затем добавьте новую запись и проверьте число заказов в соответствующей группе. Если результат предназначен для диаграммы, следующим шагом его можно превратить в массив объектов с полями label и value. Сам график должен отдельно решать вопросы порядка, единиц измерения и подписей.

orders[status!="cancelled"]{
  city: {"orders": $count($), "amount": $sum(total)}
}

Пример 5: вложенные позиции в плоские строки

Заказ содержит несколько товарных позиций, а выгрузка ожидает одну строку на позицию. Простое обращение к orders.items даст сами позиции, но может потерять удобную связь с родительским документом. В нашем правиле перед переходом к items сохраняется id заказа в переменную $order.

Каждая выходная строка получает orderId, sku, quantity и lineTotal. Для второй позиции R-101 это VISIT, количество 2 и сумма 6000. Восемь позиций шести заказов превращаются в восемь строк. Такой формат удобно передать в CSV, подготовить к созданию Excel или загрузить в таблицу аналитики.

При реальном обмене не забывайте о единицах и округлении. В примере цены представлены целыми рублями, а количество — целым числом. Если появляются дробные количества, скидки и налоги, нужно согласовать порядок расчёта и допустимую точность. Указанная в заказе итоговая сумма может отличаться от простого произведения цены и количества, поэтому сверка итогов остаётся отдельной проверкой.

[orders.($order := id; items.{
  "orderId": $order, "sku": sku,
  "quantity": qty, "lineTotal": qty * price
})]

Пример 6: строки, null и отсутствующие поля

Контакты часто приходят из разных источников. У одного имени есть лишние пробелы, email записан заглавными буквами, телефон равен null. У другого контакта ключа phone вообще нет. Шестая задача показывает, как подготовить одинаковую структуру для последующего импорта, не меняя исходные данные.

Функция trim убирает внешние пробелы, lowercase меняет регистр email. Условие для телефона отдельно проверяет наличие значения и сравнивает его с null. В нашем контракте оба случая превращаются в пустую строку. Это решение принято именно для демонстрации: другая система может требовать null или полное отсутствие ключа.

Нормализация не доказывает, что адрес электронной почты существует, а номер телефона принадлежит клиенту. Она также не должна молча превращать любое ошибочное значение в удобную строку. Если API внезапно прислал объект вместо имени, полезнее получить понятную ошибку и исправить интеграцию. Для обязательных полей добавьте проверку типа и сообщение, позволяющее найти проблемную запись.

[contacts.{
 "name": $trim(name), "email": $lowercase(email),
 "phone": $exists(phone) and phone != null ? phone : ""
}]

Пример 7: адаптер вложенного вебхука

Вебхук часто содержит техническую оболочку и вложенную полезную нагрузку. В нашем документе событие order.paid содержит номер заказа, сумму в копейках, валюту и имя клиента. Выражение собирает компактный объект с полями type, order, amount, currency и client. Его проще передать дальше по вашему приложению.

В мастерской 1500000 копеек превращаются в 15000 рублей. Это наглядный перевод единиц, а не универсальная финансовая модель. На сервере полезно сохранять исходное целочисленное значение и валюту, избегая неоговорённых операций с дробными числами. Если внешняя система использует другие минимальные единицы, делитель нельзя без проверки закреплять равным ста.

JSONata не подтверждает подлинность события. До преобразования обработчик должен проверить подпись вебхука, его размер, тип и права источника. После этого обычно нужны защита от повторной обработки и запись результата в надёжное хранилище. Наш пример занимается только формой данных и не выполняет оплату, не отправляет запрос и не изменяет состояние реального заказа.

{"type": webhook.event, "order": webhook.payload.order_id,
 "amount": webhook.payload.amount_minor / 100,
 "currency": webhook.payload.currency,
 "client": webhook.payload.customer.display_name}

Пример 8: рейтинг, сортировка и ограничение результата

Для блока крупных заказов выбираем оплаченные заявки, сортируем их по сумме по убыванию и оставляем заданное число строк. При лимите два в нашем наборе первыми будут R-103 и R-101. Переключите лимит на один и проверьте, что результат остаётся массивом из одной строки.

Порядок операций здесь принципиален. Если сначала взять две исходные строки, а потом отсортировать, вы получите рейтинг только среди этих двух, а не среди всех подходящих заказов. Скобки в выражении выделяют отсортированный результат, к которому затем применяется диапазон индексов. Это маленькая деталь, которая легко превращается в ошибку показателя.

При одинаковых суммах полезен второй критерий сортировки, например номер или дата. Он делает порядок стабильным и уменьшает визуальные перестановки при обновлении. В нашем учебном наборе оплаченные суммы различаются, поэтому базовый пример проще. Для реальной страницы также определите, сколько данных вообще допустимо получать: клиентский top не заменяет серверную пагинацию большого каталога.

[(orders[status="paid"]^(>total))[[0..($limit-1)]].{
 "id": id, "client": customer, "amount": total
}]

Ноль, один и много результатов: почему форма имеет значение

Особенность JSONata, которую стоит проверить одной из первых, — обработка последовательностей. Путь может вернуть отсутствие значения, одно значение или несколько. Для разработчика таблицы это разные входы. Если компонент ожидает массив, единичное совпадение без внешнего конструктора может привести к ошибке на вызове map или length.

В наших списочных сценариях используются внешние квадратные скобки. Автоматический тест первой задачи проверяет три состояния: несколько совпадений, одно совпадение и пустой результат. Так контракт проверяется по данным, а не только по тому, что выражение не упало. Для одиночной карточки, напротив, массив может быть лишним: форму выбирает потребитель.

Отдельно различайте undefined и null. Отсутствие пути не обязательно означает ошибку JSONata; это может быть отсутствие совпадений. Мастерская показывает его понятной подписью и не предлагает скачать несуществующий JSON-результат. Если вашему API нужен явный null, задайте это правилом адаптации и зафиксируйте тестом, чтобы очередное изменение не удалило обязательное поле.

[orders[total > 999999].id]
/* Результат: [] */
[orders[id="R-103"].id]
/* Результат: ["R-103"] */

Подключение в Node.js и асинхронное выполнение

В Node.js библиотека устанавливается через npm и импортируется как обычный модуль. Сначала выражение компилируется, затем evaluate получает данные и bindings. В современной версии результат нужно ожидать через await. Если забыть ожидание, окружающий код может попытаться сериализовать Promise или продолжить работу до окончания преобразования.

Для повторяющихся доверенных правил удобно компилировать выражение один раз и применять его к разным входным документам. Но при этом параметры конкретного запроса лучше передавать через evaluate, не хранить их в общей изменяемой переменной. Это особенно важно в сервере, который одновременно обслуживает несколько пользователей.

В архиве есть tools/transform.js. Он принимает путь к JSON и путь к выражению, выводит результат в stdout, а ошибку — в stderr. Успех и неудача различаются кодом завершения процесса. Такой интерфейс подходит для цепочки подготовки данных, но сам по себе не превращает утилиту в защищённый сервис для произвольных чужих выражений.

import jsonata from "jsonata";
const rule = jsonata("[orders[status=$status].id]", {
  timeout: 700, stack: 300, sequence: 10000
});
const result = await rule.evaluate(data, {status: "paid"});
console.log(result);

Обработка ошибок и понятный ответ пользователю

Ошибки бывают на разных этапах. Неверный JSON не позволяет получить входной объект. Синтаксическая ошибка не позволяет скомпилировать выражение. Ошибка выполнения возникает уже при обработке данных, например при преобразовании неподходящей строки в число. Для интерфейса полезно различать эти случаи, чтобы человек понимал, что именно исправлять.

Мастерская показывает код ошибки, сообщение и позицию, если библиотека её сообщает. После изменения ввода старый результат сразу помечается как неактуальный. Это важнее красивого уведомления: пользователь не должен случайно скачать JSON от предыдущего выражения, пока на экране уже написано новое. Кнопка копирования также выключается до успешного пересчёта.

В серверной интеграции не отдавайте наружу полный стек и внутренние пути. В журнале можно сохранить идентификатор правила, тип события, код ошибки и корреляционный идентификатор, избегая секретов и полного персонального документа. Для пользователя достаточно сообщения о неподходящем формате и ссылки на конкретное проблемное поле, если его удалось определить.

try {
  const rule = jsonata(expression);
  const result = await rule.evaluate(input, bindings);
  return {ok: true, result};
} catch (error) {
  return {ok: false, code: error.code, message: error.message};
}

Worker, ограничения и чужие выражения

В браузере выполнение вынесено в отдельный Worker. Основная страница продолжает принимать действия, а пользователь может остановить расчёт. Если результат не приходит за две секунды, мастерская принудительно завершает Worker. Новый запуск создаёт новый экземпляр, поэтому ошибочное выражение не сохраняет скрытое состояние для следующего опыта.

Дополнительно ограничены размер ввода, длина выражения, последовательности и текст результата. Значения выбраны для небольших учебных задач, а не для любого проекта. Проверка длины результата происходит после вычисления и не является строгой гарантией ограничения памяти. Для сервера нужны отдельные решения по памяти, числу одновременных задач и времени жизни процесса.

Встроенный timeout JSONata не охватывает все возможные расходы JavaScript, в частности работу стандартных регулярных выражений. Поэтому одного параметра timeout недостаточно для публичной песочницы. Не добавляйте к JSONata функции чтения файлов или сетевых запросов без проектирования разрешений. Консольный пример в архиве рассчитан на доверенные файлы правил, подготовленные разработчиком.

const worker = new Worker("./worker.js");
const timer = setTimeout(() => worker.terminate(), 2000);
worker.onmessage = event => {
  clearTimeout(timer);
  worker.terminate();
  showResult(event.data);
};
worker.postMessage({expression, input, bindings});

Windows: локальный запуск и сохранение результата

Распакуйте проект в отдельную рабочую папку и откройте там PowerShell. Проверьте node –version и npm –version. В Windows удобно использовать npm.cmd: это позволяет не зависеть от политики выполнения PowerShell для скрипта npm.ps1. Установка зависимостей выполняется из lock-файла, затем собирается public и запускаются тесты.

После npm.cmd start откройте http://127.0.0.1:8164. Терминал остаётся занят сервером, остановка — Ctrl+C. Если порт занят другим приложением, задайте переменную PORT перед запуском и откройте новый адрес. Не нужно отключать защиту системы или открывать порт в интернет ради локальной мастерской.

Для консольного преобразования используйте второй терминал. В старом Windows PowerShell перенаправление вывода может неожиданно поменять кодировку файла. В README приведён вариант через cmd для сохранения байтового вывода Node и вариант Set-Content -Encoding utf8 для PowerShell 7. После выгрузки откройте JSON и проверьте русские строки, структуру и количество записей.

npm.cmd ci --ignore-scripts
npm.cmd run build
npm.cmd test
npm.cmd start
# В другом терминале из каталога проекта:
node tools/transform.js public/examples/data.json public/examples/filter.jsonata

Linux и VPS: как применить проект на сервере

На Linux команды сборки такие же: npm ci, npm run build и npm test. Консольную утилиту можно включить в подготовку выгрузки, запускать из задания планировщика или вызывать из внутреннего процесса. Укажите абсолютный путь к Node и рабочему каталогу, потому что окружение фоновой задачи часто отличается от вашей интерактивной оболочки.

Для публикации самой мастерской Node-сервер не нужен: содержимое public является статическим сайтом. Скопируйте его в отдельный каталог веб-сервера и настройте домен в Caddy или Nginx. Не публикуйте весь проект целиком. Внутренние JSON, переменные окружения и серверные конфиги должны оставаться вне доступного по HTTP каталога.

Пример ниже предполагает уже установленный Caddy и ваш домен вместо jsonata.example.org. Сначала настройте DNS, проверьте доступ к портам и права чтения файлов, затем проверьте конфигурацию перед reload. HTTPS относится к настройке сервера, а не к функциям JSONata. В статье не предполагается, что учебный домен уже существует или что сертификат для него был выпущен.

jsonata.example.org {
    root * /var/www/jsonata-demo
    file_server
    header X-Content-Type-Options nosniff
}
# После добавления блока в Caddyfile:
# sudo caddy validate --config /etc/caddy/Caddyfile
# sudo systemctl reload caddy

Тесты, контракт результата и обновление библиотеки

Для каждого прикладного правила полезны входной документ и ожидаемый выход. В проекте проверяются фильтр, карточки, показатели, группировка, разворачивание позиций, контакты, вебхук и рейтинг. Дополнительные тесты рассматривают неверный синтаксис, ошибку выполнения и срабатывание ограничений. Это помогает заметить изменение поведения до публикации нового правила.

Результат JSONata может иметь особенности внутреннего представления JavaScript-объекта. Наши тесты сравнивают сериализованный JSON-контракт, потому что именно он используется при обмене. Это не означает, что любую разницу нужно игнорировать: порядок элементов, числовые значения, отсутствие поля и null по-прежнему проверяются строго.

После обновления зависимости повторите не только npm test, но и несколько действий в браузере. Нужно убедиться, что Worker загружается, ошибка не оставляет доступным старый результат, файл скачивается, а длинные строки не расширяют страницу на телефоне. Закреплённая версия делает проверку воспроизводимой; само наличие package-lock не заменяет решение о том, когда и зачем обновляться.

npm test
node tools/transform.js public/examples/data.json public/examples/filter.jsonata > result.json

Как перенести пример в свой сервис

Выберите один понятный участок интеграции, например преобразование ответа каталога в карточки. Сохраните обезличенный образец входа, опишите ожидаемый выход и напишите короткое выражение. Затем проверьте пустой набор, одну запись, отсутствующие необязательные поля и заведомо неподходящий тип значения. Это даст больше пользы, чем немедленная попытка описать весь обмен одним длинным правилом.

Далее определите место выполнения. Для небольшого локального преобразования данных интерфейса подходит браузер. Для обязательной логики, общей для всех клиентов, обычно нужен сервер. Не доверяйте клиентскому результату для прав доступа, расчёта платежа или изменения учётных данных: пользователь управляет своим браузером и может изменить любой скрипт.

Храните правила рядом с версией контракта и тестами. Когда внешний API изменится, будет понятно, какое преобразование относится к какому формату. Отдельно продумайте журнал ошибок и повторную обработку: JSONata решает форму данных, а доставка, устойчивость и наблюдаемость остаются ответственностью приложения. Начните с небольшой проверяемой задачи и расширяйте её, когда исходный вариант уже надёжно работает.

Источники и материалы для продолжения

Официальная документация полезна для проверки синтаксиса и особенностей конкретной версии. Начните с обзора языка, затем прочитайте модель обработки последовательностей и раздел об ограничениях выполнения. Эти темы напрямую влияют на форму результата и на то, где допустимо запускать выражения, полученные от пользователя.

Исходники нашей мастерской дополняют документацию прикладными задачами и проверяемыми данными. Вы можете использовать собственный код под MIT, сохранив уведомление о лицензии. Лицензии JSONata и Bootstrap вложены отдельно. Перед переносом в продукт замените вымышленные данные, проверьте свои контракты и настройте ограничения под фактическую нагрузку.

Если после эксперимента у вас остался работающий файл выражения и тестовый JSON, следующий шаг уже конкретен: подключить их к одному реальному участку приложения. Не обязательно переписывать существующий код целиком. Адаптер на границе интеграции, небольшая сводка или подготовка выгрузки позволяют оценить инструмент без большого изменения архитектуры.

• JSONata: обзор языка
• Модель обработки последовательностей
• API JavaScript и bindings
• Ограничения выполнения
• Исходный код JSONata