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
@Component
public 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.
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.