Чем вы пользуетесь для валидации JSON-а?

Самописными костылями, конечно же. Правда я их не обновлял на гитхабе.

Тоже с горя начал писать «строгий» валидатор, со схемой, рекурсивными типами, размерными интами и «правильными» структурами данных, но вовремя остановил себя, осознав, объем работ :)

Странно, просто. Тема вроде актуальная, а сказано мало. Вот и захотелось узнать кто как справляется

Тоже с горя начал писать «строгий» валидатор, со схемой, рекурсивными типами, размерными интами и «правильными» структурами данных, но вовремя остановил себя, осознав, объем работ :)

Я бы не сказал, что прям много. Меня мой костыль на 10 кб вполне устраивает. Надо добавишь набор типов, цепочку типов и/или условия типа «number && int && int_gt0» но это +2 цикла и несколько костылей.
И да, я тоже с горя сел писать, посмотрев на json-schema. Ничего страшного, больше бы проковырялся там с копипастом или какой-нибудь хернёй, которая разворачивается в json-schema.

Лучше пойду с горя protobuf в браузер прикручу)

Ооо. Жестоко.

В Гугле так и делают, например, до сих пор не обанкротились.

Ну и раз речь про браузер, то есть io.ts, хотя лично мне мне без валидации нравится больше (при условии что джейсон приходит из доверенного источника, конечно).

io.ts

Ого. Мудреная штука. С наскоку не разобрался. Читну на досуге

https://crates.io/crates/validators

А чего ты хочешь добиться этой валидацией на клиенте?

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

ЗЫ: Посмотрел protobuf. Уже было обрадовался, что proto-compiler умеет JS генерить по схеме. А затем глянул на этот JS и поплохело. Closure compiler из всех щелей торчит. В гугле JS-генератор для себя, а не для людей писали

А какова изначальная задача?

Какова семантика твоих json-данных?

Если это хранение какой-то инфы, то имеет смысл использовать готовые валидаторы, он точно производительнее и сильно экономят время.

А если у тебя обмен в формате json, то... забить.

Проверяй бизнес-логику, когда данные распакуешь/десериализуешь, зачем валидировать в формате json?

Если все же очень нужно (ну не доверяешь ты клиенту или серверу), то сразу и пользуй protobuf, раз начал копать. gRPC как раз для этого.

Какова семантика твоих json-данных?

Никакова. Теоретизирую на досуге. Скорее просто интересно как остальной честной народ справляется. Пока что складывается впечатление, что все забивают, и лишь crutch_master валидирует самописным костылем :)

А если у тебя обмен в формате json, то... забить

Можно. Забить дело хорошее)

Проверяй бизнес-логику, когда данные распакуешь/десериализуешь, зачем валидировать в формате json?

А чем, в данном случае, отличается проверка в бизнес-логике от валидации JSON по схеие?

https://json-schema.org/

Проверяй бизнес-логику, когда данные распакуешь/десериализуешь, зачем валидировать в формате json?

А чем, в данном случае, отличается проверка в бизнес-логике от валидации JSON по схеие?

Тем, что ты так или иначе будешь проверять бизнес-логику, а не сами json-данные в вакууме. Особенно актуально для формата обмена.

Если же ты хочешь конкретно проверить что тебе int пришел, а не float и др. подобные штуки, то gRPC и protobuf как раз для этого.

если и клиент и сервер мною написаны
Поменял, допустим, я модель на сервере, а на клиенте забыл.

а как у тебя дела с архитектурой? Разделение на слои даёт куда большую безопасность, чем любая валидация.

Если ты сделал рефакторинг моделей в сервере, то на транспортном слое изменений быть не должно - тогда и ломаться нечему.

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

Что тут можно в рантайме проверять? Что кто-то не задеплоил несовместимую версию сервера или что? Тут не валидация нужна, а административные мероприятия.

а как у тебя дела с архитектурой?

Как у всякой жс-макаки. UML-диаграм не строим

...то и на клиенте должны быть симметричные изменения -

даже если ты их забудешь сделать, то при тестировании в тот жде день обнаружишь и починишь

This. Чтобы при запуске не невнятная ошибка выскочила, а прям на входе, на языке белых людей «Input error. The field 'skidka' of the wrong type». Потомучто, когда ошибка в глубокой логике выскакивает, я, зачастую, далекооо не сразу понимаю, что дело было в формате данных

Тем, что ты так или иначе будешь проверять бизнес-логику, а не сами json-данные в вакууме

В современных веб-фреймворках, «json-данные в вакууме» называются State и, подчас, никакой другой бизнес-логики под собой не имеют :)

В питоне:
- сразу пытаюсь заполнить объект, который аналогичен инстансу модели, данными из json
- проверяю на всякие SQL приколы (но с этим обычно ORM справляется)

А если в json данные, непригодные для заполнения инстанса?

rust serde

Как он поведет себя, если пришла структура данных не с теми полями или поля не того типа? Возможно ли разом сериализовать например, объект структуру, в которую вложено еще пара структур и массив? Декларативно, а не if-ами

А нужна именно валидация произвольного JSON? Так-то JSON можно описывать на Swagger/OpenAPI.

Как он поведет себя, если пришла структура данных не с теми полями или поля не того типа?

Вернёт подробную ошибку.

Возможно ли разом сериализовать например, объект структуру, в которую вложено еще пара структур и массив? Декларативно, а не if-ами

Можно.

но, складывается впечатление, что мало кто ей пользуется.

Потому, что ленивые жопы. Мало кто пользуется json-schema, мало кто пишет тесты, мало кто моет руки после туалета.

Это чущь

а чем вы пользуетесь для проверки входных данных на адекватность?

Разумеется, ничем. Я сам адекватный и этого достаточно.

Подробнее.

Я посылаю или принимаю JSON данные в своих программах на Java (то же было бы справедливо для других популярных языков). В обоих случаях использую свои Java-объекты с нужными полями и библиотеку преобразования объектов из/в JSON (и XML). Таким образом, возможно преобразование между XML и JSON, а в XML есть достаточные средства проверки правильности структуры (DTD и XML Schema). Но у меня необходимости проверки правильности средствами XML пока не возникало.

Проблемы. При приёме JSON в своей программе - авторы JSON не всегда утруждают себя точным описанием его структуры. Поэтому соответствующий Java объект в моей программе не всегда сразу бывает правильный - или некоторые поля оказываются необязательными, или в JSON появляются непредусмотренные поля, или вдобавок (или вместо полей данных) выдаются коды ошибки и/или её сообщения. Все такие неожиданности быстро улавливаются при отладке и не доставляют затруднений. Поэтому хоть я много пишу и читаю JSON и XML, формальные средства проверки правильности JSON как-то не требуются.

Ещё в JSON может оказаться неправильный формат дат. Если у меня они в виде текста, то использую формат ISO-8861 (или привожу к нему полученный JSON).

json

json-schema

статическая типизация

вы упоротые? json стали использовать повсеместно, вместо xml, как раз из-за его легковесности и динамичности. Если сильно надо статически проврять, что request имеет правильный формат - используйте xml + xsd.

Та валидация, о которой вы говорите, должна получатся как побочный эфект конвертации json из риквеста в модель, которая дальше передается в бизнесс-логику. Не смогли сконвертировать -> риквест не правильный -> http response 400

Ну а если проблема возникает из-за того, что json из риквеста не конвертируется в модель, а напрямую используется как модель, то у меня плохие новости.

каждый json документ имеет схему и валидируется при приёме.
при этом активно используются дефолтные значения, которые заполняются валидатором, в случае отсутствия полей (старая версия api, например)
если на валидации не упало, передаётся в gson.
на клиенте нет смысла валидировать. если бек отдаёт ерунду, то это очень плохо.

Единственный разумный вариант. Еще и на парсинге JSON время сэкономишь.

Ну тогда и нечего их валидировать.

Ты хочешь найти ошибку в сериализации / десериализации / передачи state?

Это вроде обычно тестами проверяется и больше трогать не нужно.

А если тебе нужна валидируемая структура по какой-то причине, то используй, как уже писали, что более внятное для этих целей - xml, protobuf и пр.

Все это «в json тоже можно схемами» - от лукавого. Из буханки троллейбус.

https://capnproto.org/

Чтобы при запуске не невнятная ошибка выскочила, а прям на входе, на языке белых людей «Input error. The field 'skidka' of the wrong type». Потому что, когда ошибка в глубокой логике выскакивает, я, зачастую, далекооо не сразу понимаю, что дело было в формате данных

Еще это хорошо для того, чтобы не распихивать везде по коду проверки на тип данных, undef, null и прочее. Если json прошел валидатор, то уже имеешь представление о том что там может быть и лишнего не кодить не нужно. Плюс, если схема компактная и повторяет структуру данных (как у меня) по ней легко потом понять, какой формат нужен и для чего. Можно прям с неё генерить доки.

Ну а если проблема возникает из-за того, что json из риквеста не конвертируется в модель, а напрямую используется как модель, то у меня плохие новости.

Сейчас бы кодить на динамическом яп модели как на яве.

валидации JSON по схеие

Это какой-то JSON не XML SOAP. Ну так, придумали формат, но не придумали валидацию, теперь вот бегают с более или менее удобными костылями, а большинство вообще положили.

json-данные в вакууме. Особенно актуально для формата обмена

А мужики то и не знают. man XSD schema

XML не нужно. Отстаньте уже с ним. Я, например, программирую конфигами в js/json свои поделки, нахрена мне ваш xml там?

что значит «не придумали» и «костыли»? у json есть схемы против которых можно валидировать. при этом, драфты схем постоянно улучшаются.

Будут null или отказ. ORM же и модели!

Ничего против XML и его схем не имею, но сам давно не использую, он морально устарел.

Жирные они, слишком, прямо как твой ответ.

Чтобы послать парочку парамтров в сраном корпорате через XML это занимает просто нереальные объемы.

Вот тут, кстати, protobuf слегка посасывает и json-схеме и твоему костылю. Структуры проверит, string от float отличит, а вот более тонкие проверки все-равно придется в логике валидировать. Например, что строка соответствует регулярке или инт в нужном диапазоне

Будут null или отказ

А может и проглотит кривые данные. Динамика же. В питоне менее вероятно, а вот в жс только в путь :)

Вот тут, кстати, protobuf слегка посасывает

Я смотрел какую-то конференцию с highloada, там пацаны тоже делали protobuf, но в итоге забили, потому что оверхед для json не такой уж и большой, по сравнению с удобством его использования.

Например, что строка соответствует регулярке или инт в нужном диапазоне

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

Да на js тоже можно наделать объектов, сеттеров, которые будут выкидывать исключения при кривом присваивание. Нужно ли только это. Pipeline как-то проще и понятнее, чем оопота с многослойками.

Хотелось бы узнать, а чем вы пользуетесь для проверки входных данных на адекватность?

Как и все профессионалы с нашего раёна я сначала парсю данные, а потом ловлю эксепшен если парсинг упал.

оверхед для json не такой уж и большой, по сравнению с удобством его использования

Есть такое. Нативный JSON.parse быстрее и эффективнее родит js-объекты, чем ненативный protobuf-парсер. С другой стороны, если выбирать между json-schema и *.proto, то последний выглядит адекватнее )

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

Зачем такое?

Зачем такое?

Что-нибудь из условий бизнес-логики. Например не должно быть двух записей (объектов в массиве) за один месяц. Если такое есть надо закатывать истерику.

json-schema

Он избыточный сильно. Как его руками редактировать и писать везде эти name, type, description, etc.

serde - фреймворк сериализации, который упрощает общий код для всех сериализаторов, отчасти потому что в Rust нету reflection. По сути это почти zero-cost превращатель структур в более богатые структуры. Вот за них уже берется сериализатор хоть в json, хоть в MessagePack.

Хуже становится когда формат сериализации более мощный, чем временный формат serde. Например до сих пор дикие муки с созданием сериализатора в xml.

Serde ещё слабо помогает работать с сериализаторами для межязыкового взаимодействия, приходится дуплицировать схему, в зависимости от реализации.

Он избыточный сильно. Как его руками редактировать и писать везде эти name, type, description

Да вроде норм. Писал, проблем не испытал. Так можно избежать копипасты в типах. Меня больше тревожат реализации. Но не должен валидатор (без парсера, ибо сама схема в json) в минифицированном/обфусцированном виде весить 263КБ! Это какая-то не норма. Почему так много даже разбираться не хочется

минифицированном/обфусцированном виде весить 263КБ

Действительно кошмар какой-то. Вроде и зависимостей не много.