Ограничения — аннотациями Bean Validation на полях DTO (@NotBlank, @Email, @Size, @Positive), проверка — **@Valid на параметре контроллера, ошибки — в @RestControllerAdvice** в едином формате (ProblemDetail с полями).
sottoList<@Valid Item>А ещё Бизнес-правила (уникальность email) — в сервисе, а не аннотацией
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Объявление правил:
public record CreateUserRequest(
@NotBlank @Size(max = 80) String name,
@NotBlank @Email String email,
@Valid @NotNull AddressDto address,
@Size(max = 10) List<@NotBlank String> tags) {}Проверка: @PostMapping ... create(@Valid @RequestBody CreateUserRequest req). При нарушении Spring бросает MethodArgumentNotValidException (для @RequestBody) или HandlerMethodValidationException (Spring 6.1+, для параметров метода); по умолчанию — 400.
Единый ответ: в @RestControllerAdvice превращать MethodArgumentNotValidException в ProblemDetail со списком ошибок полей (field, message), чтобы клиент мог подсветить их в форме.
Группы и параметры: @Validated(OnCreate.class) — разные правила для создания и изменения; @Validated на классе сервиса — проверка параметров методов (@NotNull, @Min на аргументах).
Где граница: аннотации — для формата и обязательности. Правила, требующие данных (email уже занят, товар закончился), — в сервисе с понятным исключением (409, 422). Свои ограничения — аннотация + ConstraintValidator.
Один верный вариант. Подумайте, потом откройте ответ.
Bean Validation и @Valid/@Validated, превращение ошибок в ответ, @ControllerAdvice и единый контракт, ProblemDetail (RFC 7807), multipart и interceptors.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.