I found another approach that works. The basic problem is that you want to have a list as your input payload for your service, but javax.validation won't validate a list, only a JavaBean. The trick is to use a custom list class that functions as both a List and a JavaBean:

@RequestBody @Valid List<CompanyTag> categories

Change to:

@RequestBody @Valid ValidList<CompanyTag> categories

Your list subclass would look something like this:

public class ValidList<E> implements List<E> {    @Valid    private List<E> list;    public ValidList() {        this.list = new ArrayList<E>();    }    public ValidList(List<E> list) {        this.list = list;    }    // Bean-like methods, used by javax.validation but ignored by JSON parsing    public List<E> getList() {        return list;    }    public void setList(List<E> list) {        this.list = list;    }    // List-like methods, used by JSON parsing but ignored by javax.validation    @Override    public int size() {        return list.size();    }    @Override    public boolean isEmpty() {        return list.isEmpty();    }    // Other list methods ...}

1 TL;DR

I tried to use Paul's method in my project, but some people said it's too complex. Not long after that, I find another easy way which works like code below:

@Validated@RestController@RequestMapping("/parent")public class ParentController {  private FatherRepository fatherRepository;  /**   * DI   */  public ParentController(FatherRepository fatherRepository) {    this.fatherRepository = fatherRepository;  }  @PostMapping("/test")  public void test(@RequestBody @Valid List<Father> fathers) {  }}

It works and easy to use. The key point is the @Valiated annotation on the class. Btw, it's springBootVersion = '2.0.4.RELEASE' that I use.

2 Exception handling

As discussed in comments, exceptions can be handled like code below:

@RestControllerAdvice@Componentpublic class ControllerExceptionHandler {  /**   * handle controller methods parameter validation exceptions   *   * @param exception ex   * @return wrapped result   */  @ExceptionHandler  @ResponseBody  @ResponseStatus(HttpStatus.OK)  public DataContainer handle(ConstraintViolationException exception) {    Set<ConstraintViolation<?>> violations = exception.getConstraintViolations();    StringBuilder builder = new StringBuilder();    for (ConstraintViolation<?> violation : violations) {      builder.append(violation.getMessage());      break;    }    DataContainer container = new DataContainer(CommonCode.PARAMETER_ERROR_CODE, builder.toString());    return container;  }}

Taking http status code as representing network is ok and only first violation message is returned here. You may change it to satisfy customized requirements.

3 How it works (code part)

With @Validated on class level, parameters of methods are validated by what called method-level validation in spring boot, which is not only worked for controllers, but any bean the IOC container managed.

• Spring boot docs about method level validation
• A more detailed blog with test about method level validation

By the way, the methods in method level validation (short as validation A) is enhanced by

• org.springframework.validation.beanvalidation.MethodValidationInterceptor

while the typical spring boot controller methods validation (short as validation B) is processed in

• org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor

Both of them lead the actual validation operation to org.hibernate.validator.internal.engine.ValidatorImpl by default, but the methods they call are different, which leads to the differences in validation logic.

• MethodValidationInterceptor call validateParameters method in ValidatorImpl
• RequestResponseBodyMethodProcessor call validate method in ValidatorImpl

They are different methods with different functions, so lead to different results in validation A/B, the typical point is the validation of list object:

• A triggers constraint check on element of collection object while B not

4 How it works (specification part)

The JSR-303 defines functions of the methods we discussed above.

validate method is explained in the validation method part, and the implementation must obey the logic defined in validation routine, in which it states that it will execute all the constraint validation for all reachable fields of the object, this is why element of List object (or other collection instance) cannot be validated via this method - the elements of the collection are not fields of the collection instance.

But validateParameters, JSR-303 actually doesn't treat it as main topic and put it in Appendix C. Proposal for method-level validation. It provides some description:

The constraints declarations evaluated are the constraints hosted on the parameters of the method or constructor. If @Valid is placed on a parameter, constraints declared on the object itself are considered.validateReturnedValue evaluates the constraints hosted on the method itself. If @Valid is placed on the method, the constraints declared on the object itself are considered.public @NotNull String saveItem(@Valid @NotNull Item item, @Max(23) BigDecimal price)In the previous example,- item is validated against @NotNull and all the constraints it hosts- price is validated against @Max(23)- the result of saveItem is validated against @NotNull

and exclaim that Bean Validation providers are free to implement this proposal as a specific extension. As far as I know, the Hibernate Validation project implements this method, makes constraints works on the object itself, and element of collection object.

5 Some complain

I don't know why the spring framework guys call validate in RequestResponseBodyMethodProcessor, makes lots of related questions appeare in stackoverflow. Maybe it's just because http post body data usually is a form data, and can be represented by a java bean naturally. If it's me, I'll call the validateParametes in RequestResponseBodyMethodProcessor for easy use.

@Paul Strack's great solution mixed with Lombok magic:

@Datapublic class ValidList<E> implements List<E> {    @Valid    @Delegate    private List<E> list = new ArrayList<>();}

Usage (swap List for ValidList):

public ResponseEntityWrapper updateMapTheme(        @RequestBody @Valid ValidList<CompanyTag> categories, ...)

(Needs Lombok, but if you don't use it already you really want to try it out)