|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Под JSR bean validation можно понимать как родные валидаторы от java, так и валидаторы средствами spring`a, разные objectmapper`ы и т.д. Под json schema validation подразумевает пока что сторонние либы, которые могут по имеющейся схеме валидировать json объект. Собственно вопрос таков: есть некий rest сервис, и у него есть некий контроллер: Код: java 1. 2. 3. 4.
Вот первый вариант. Аннотация @Valid отработает после попытки десериализации тела входящега запроса к обхекту класса NewUser. Код: java 1. 2. 3. 4. 5.
Вот второй вариант, тут мы получаем строку и как-то ее валидируем, причем согласно заранее припасенной схеме. Второй вариант сейчас набирает обороты и я встречаю его все больше и больше. Кто сталкивался? Какие плюсы и минусы? Зачем используете(если используете)? Почему отказались(если отказались)? https://beanvalidation.org/1.0/spec/ http://json-schema.org/ https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/validation.html ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 12:34 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Озверин, Ну дак кто провалидирует как не парсер выбранный лично прогером? И что делать с уже новым json5? авторЧисла могут быть в шестнадцатеричном виде, начинаться или заканчиваться десятичной точкой, включать Infinity, -Infinity, NaN и -NaN, начинаться со знака +. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 14:06 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Озверин, https://json5.org ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 14:12 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
ОзверинСобственно вопрос таков: есть некий rest сервис, и у него есть некий контроллер Это не вопрос, это введение к вопросу. Умение разделять сущности есть одно из полезнейших качеств программиста. ОзверинКакие плюсы и минусы? А вот это уже вопрос. И ответ таков - в схеме автор декларативно задаёт правила валидации. Декларативно = гуд. Если возможностей схемы достаточно для предметной области - пользовать схему. Если возможностей недостаточно - писать валидатор самому (полностью, не деля на схему и самопал). ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 16:34 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
alex55555, +1 Ну и на спринг наеду. Куда только спринг не лезет)) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 16:46 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Смотрите, что получается. Допустим, мы где-то на сайте заполняем какую-то форму - создаем новую компанию. У компании есть поле "name". Поле можно заполнить исходя из бизнес логики(минимальная-максимальная длина, допустимые символы). Уже на уровне view мы проводим первую валидацию Далее, пользователь заполнил имя и нажал - создать. Запрос к rest сервису, туда отправился json, и уже в контроллере бэка мы проводим следующую валидацию на этапе десериализации объекта, к примеру. Далее, мы преобразуем нашу DTO в DB entity и пытаемся сохранить, и на этапе сохраенния тоже будет валидация(как те, которые мы проверяли вещи, вроде максимальной длины поля, так и более экстравагантные, вроде constraint`ов). Минимум в трех местах мы проверяем входящие данные. И проблема тут заключается не в том, что медленно или много, а в том, что вся эта валидация хорошо была б согласована во всех слоях: то есть после изменения схемы в БД надо бы поменять валидацию на уровнях выше. А то было б странно, что пользователю говорит, что макс длина - 70, а в базе, допустим, уже 60. В моем случае все это "устаканивается" после создания issue от пользователя о том, что мол де столько то символов написано, а реально - столько то. Может у вас как-то более согласовано? Как? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 17:03 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Petro123alex55555, +1 Ну и на спринг наеду. Куда только спринг не лезет)) спринг удобен, почему бы и нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 17:04 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
ОзверинPetro123alex55555, +1 Ну и на спринг наеду. Куда только спринг не лезет)) спринг удобен, почему бы и нет?нарушает закон федеральный о конкуренции) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 17:23 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
ОзверинМинимум в трех местах мы проверяем входящие данные.при rest клиент не зависим и внешний от вас. Делайте другое свое API и не проверяйте. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 17:26 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Озверин, Кстати, если микросервисы, то и между ними будете проверять. Нет золотой пули. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2019, 17:36 |
|
JSR bean validation vs json schema validation
|
|||
---|---|---|---|
#18+
Озверинвся эта валидация хорошо была б согласована во всех слоях ... Как? Единый валидатор. Например, при использовании GWT у меня не возникает проблем с одинаковой валидацией на клиенте и на сервере. Но можно и в разных языках, например, одни и те же декларативно заданные параметры использовать. Логику БД (констрэйнты) делают для предотвращения грубых ошибок разработчиков, это не валидатор. Валидатор валидирует юзеров. А констрэйнты - девелопера. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2019, 13:25 |
|
|
start [/forum/topic.php?fid=59&fpage=33&tid=2121538]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 363ms |
total: | 482ms |
0 / 0 |