qatoolqa.ru

Проверка JSON по схеме онлайн

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

Данные

1 Вставьте данные — JSON-ответ 2 Нажмите «Построить из данных» 3 Готово: черновик схемы — правьте его руками

Схема

Проверка

Что здесь важно знать

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

Черновик — это черновик. Построенная из одного ответа схема считает обязательными ВСЕ поля, которые в нём были, — из одного примера нельзя узнать, какие из них могут отсутствовать. Уберите из required необязательные, добавьте ограничения (pattern для строк, minimum для чисел) — и только потом проверяйте по нему следующие ответы.

Готовая схема живёт в контракте, а не в самом ответе: файл OpenAPI/Swagger (раздел components.schemas), спека в репозитории бэкенда, документация API. Если у команды есть Swagger UI, схему ответа видно на странице эндпоинта в блоке Schema — оттуда её можно скопировать. Данные — из DevTools → Network → запрос → вкладка Response.

Пустая схема {} пропускает всё, и это не поломка. Схема описывает ограничения; нет ограничений — нет ошибок. Если проверка неожиданно зелёная, первым делом посмотрите, есть ли в схеме required и properties: без них объект «соответствует» почти всему.

Лишние поля по умолчанию проходят. Пока в схеме не написано "additionalProperties": false, объект с незадокументированными полями считается валидным — так устроен стандарт. «Бэкенд прислал лишнее, а проверка молчит» — почти всегда ровно этот случай.

Строка $schema: "https://json-schema.org/…" внутри схемы — не ссылка и не реклама. Это машинный идентификатор версии стандарта — как <!DOCTYPE html> в разметке: по нему валидаторы понимают, по каким правилам читать схему. Никто по этому адресу не ходит. Инструмент читает его и проверяет по правилам названного черновика: draft-04, draft-07, 2019-09 или 2020-12. Если поля нет, берётся 2020-12 — по нему написаны свежие OpenAPI 3.1. Разница между черновиками не косметика: например, exclusiveMinimum в draft-04 — это true/false рядом с minimum, а начиная с draft-06 — само число.

Текст ошибок — на английском. Его отдаёт валидатор дословно, и это сделано намеренно: тот же текст выдают библиотеки в автотестах, и по нему удобно искать. Путь в колонке «Где» — это JSON Pointer: /items/2/price означает «поле price третьего элемента массива items».

Кнопка «Подставить пример» кладёт учебную пару: схему и ответ с двумя ошибками.

Частые вопросы

Данные уходят на сервер?

Нет: проверяет библиотека, лежащая на этом же сайте, прямо в браузере. Страница работает и офлайн.

Какие версии JSON Schema поддерживаются?

draft-04, draft-07, 2019-09 и 2020-12 — версия читается из поля $schema; без него берётся 2020-12, по нему написаны свежие OpenAPI 3.1.

Почему проверка пропускает лишние поля?

Так устроен стандарт: пока в схеме нет "additionalProperties": false, незадокументированные поля считаются валидными. Это самая частая причина неожиданно зелёной проверки.