JSON валиден, но API не принимает - где заканчивается formatter
Почему JSON formatter ловит синтаксис, но не проверяет обязательные поля, типы и бизнес-правила API. Когда нужен JSON Schema, OpenAPI или Zod.
Payload красиво отформатирован, зелёная отметка "JSON валиден" есть, а endpoint всё равно отвечает 400 Bad Request. Ошибка выглядит обидно: JSON же нормальный. Только API не обещал принимать любой нормальный JSON.
JSON formatter решает узкую задачу: разобрать строку как JSON, показать parser error, расставить отступы или сжать пробелы. Это быстрый способ найти лишнюю запятую, незакрытую кавычку или комментарий, который случайно попал из JavaScript object literal.
Но formatter не знает контракт вашего API.
Что проверяет formatter
Если документ проходит через JSON.parse, значит синтаксис корректный: строки в двойных кавычках, запятые на местах, числа без лишних символов, объекты и массивы закрыты. Для чтения логов, ответа API или request body из issue этого часто достаточно.
Пример синтаксически валидного payload:
{
"email": "user@example.com",
"age": "42",
"status": "enabled"
}
Для parser всё хорошо. Для API может быть нет: age ждут числом, status принимает только active | blocked, а рядом ещё обязателен profileId. JSON валиден, request невалиден.
Что проверяет schema validation
Schema validation отвечает на другой вопрос: подходит ли структура под контракт. Там можно описать обязательные поля, типы, минимальную длину строки, enum, формат даты, вложенные объекты и массивы.
Вот где нужны JSON Schema, OpenAPI validator, Zod, Yup или собственная валидация в backend-коде. Они не заменяют formatter; они стоят уровнем выше. Formatter сначала делает документ читаемым и синтаксически чистым, schema потом проверяет смысл для конкретного API.
Быстрая диагностика 400
| Симптом | Где смотреть |
|---|---|
Unexpected token в formatter | Синтаксис JSON |
API пишет field is required | Контракт endpoint |
API пишет must be number | Тип поля |
API пишет unknown enum value | Разрешённые значения |
| API принимает в dev, но не в prod | Версия схемы или feature flag |
Если ошибка приходит от formatter - чините JSON. Если ошибка приходит от API - открывайте контракт. Swagger, OpenAPI spec, JSON Schema в репозитории, DTO-класс, тесты handler. Красивые отступы больше не помогут.
Где devdeck полезен в этом процессе
Сначала вставьте payload в JSON formatter. Если он не парсится, до API ещё рано. Исправьте синтаксис, скопируйте форматированный вариант и только потом сравнивайте с контрактом.
Если payload содержит секреты, токены или внутренние id, проверьте Network tab: devdeck formatter работает в браузере, source payload не должен уходить на сервер. Для совсем больших JSON, где вкладка начинает думать секундами, лучше jq или локальный test fixture.
Закрывать такую ошибку удобно в два шага: formatter для грамматики, schema validator для контракта. Если поменять порядок, можно долго доказывать API, что строка с числом почти то же самое, что число.
Вопросы
JSON formatter проверяет JSON Schema?
Нет. Devdeck JSON formatter проверяет синтаксис JSON и форматирует документ. Schema validation нужно делать отдельным инструментом или в коде.
Почему JSON.parse говорит, что всё валидно, а API возвращает 400?
Потому что JSON.parse проверяет только грамматику JSON. API может требовать конкретные поля, типы, enum values, формат даты или взаимосвязь между полями.
Можно ли доверять formatter перед отправкой payload в production?
Formatter полезен как быстрый синтаксический фильтр. Для production payload нужен контракт: JSON Schema, OpenAPI, Zod, Yup или тест рядом с кодом.