Очень понравилась ваша реализация метода поиска - Загрузка сущностей :: Документация Jmix
Мы из коробки получаем endpoint который поддерживает пагинацию, возможность фильтрации по любому полю, всевозможные типы операций по data type и т.д.
В процессе изучения документации и исходников у нас возникли вопросы.
В рамках наших бизнес потребностей, нам бы хотелось:
- чтобы мы могли валидировать входящий запрос, из коробки мы этого не получаем
приведу пример
у нас есть сущность Company с атрибутом - inn, данный атрибут имеет ограничение на длину, например до 12 символов
в сущности соответвенно указываю аннотацию:
@Column(name = “INN”, nullable = false, length = 12)
если у нас на “уровне БД” максимум может быть 12 символов, то при попытке послать вот такой вот запрос с фильтром,
где мы передаем в п-р inn 30 символов, то он не должен доходить до уровня БД и мы должны получать 400 http код или хотя бы exception который мы можем смаппить на нужный нам http код в controller advice, например:
POST /rest/entities/Company/search
{
…
“filter”: {
“conditions”: [
{
“property”: “inn”,
“operator”: “=”,
“value”: “123451234512345123451234512345”
}
]
}
…
}
- неплохо было бы иметь возможность white или black list-a по набору атрибутов (property) при использовании в поле filter, sort, аналогичную настройку под типы операций (operator),
например у нас используется микросервисная архитектура,
порой очень страшно выдавать универсальный REST под всеобщее использование (наш мс это доменный мс с CRUD API), почему, потому что не на все поля есть индексы в бд, по некоторым полям не хочется разрешать поиск на вхождение например и т.д.,
хотелось бы иметь возможность что то запретить иногда, как то это лучше контролировать, вот этот пункт больше пожелание.
Планируете ли вы в каких нибудь версиях JMIX реализовать такое вот поведение для универсального REST?
А в целом очень хорошая реализация, нам очень понравился универсальный REST.