LINUX.ORG.RU

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

 ,


1

4

Здравствуйте

Вдумчивое гугление привело меня к выводу, что тема валидаторов раскрыта плохо. Да, есть json-schema, но, складывается впечатление, что мало кто ей пользуется. Есть еще ряд проектов сомнительного свойства, например joi, который умудрились сделать зависимым от node.js

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

Ответ на: комментарий от crutch_master

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

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)
Ответ на: комментарий от spoonbob

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от spoonbob

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

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

dsxl ()
Ответ на: комментарий от anonymous

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

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)
Ответ на: комментарий от spoonbob

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

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

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

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

anonymous ()
Ответ на: комментарий от spoonbob

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

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

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

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

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

dsxl ()
Ответ на: комментарий от dsxl

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

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

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

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

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

spoonbob ()

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

Shadow ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)
Ответ на: комментарий от spoonbob

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

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

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

Можно.

RazrFalcon ★★★★★ ()
import json

def is_valid_json(string):
    try:
        json.loads(string)
        return True
    except Exception:
        return False

s = '{"asdf": "qwerty"}'

if is_valid_json(s):
    print('это валидный жэсон')
else:
    print('это инвалидный жэсон')

anonymous ()

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

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

dem ()

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

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

Подробнее.

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

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

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

Partisan ★★ ()

json

json-schema

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

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

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

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

anonymous ()

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

system-root ★★★★ ()
Ответ на: комментарий от spoonbob

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

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

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

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

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

anonymous ()
Ответ на: комментарий от spoonbob

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

crutch_master ★★★★★ ()
Ответ на: комментарий от spoonbob

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

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

anonymous ()
Ответ на: комментарий от crutch_master

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

spoonbob ()
Ответ на: комментарий от spoonbob

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

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

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

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

crutch_master ★★★★★ ()
Ответ на: комментарий от spoonbob

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)

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

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

Alve ★★★★★ ()
Ответ на: комментарий от crutch_master

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

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

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

Зачем такое?

spoonbob ()
Ответ на: комментарий от spoonbob

Зачем такое?

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

json-schema

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

crutch_master ★★★★★ ()
Ответ на: комментарий от spoonbob

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

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

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

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

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 2)