團隊新來了個校招實習生靜靜,相互交流后發現竟然是我母校同實驗室的小學妹,小學妹很熱情地認下了我這個失散多年的大濕哥,后來...
小學妹:大濕哥,咱們專案里的 Controller 怎么都看不到引數校驗處理的代碼呀?但是程式運行起來,看到有是有校驗的?
大濕哥:哦哦,靜靜,你看到 Controller 類和方法上的 @Validated,還有其他引數的 @NotBlank、@Size 這些注解了嗎?
小學妹:看到了,你的意思是這些注解跟引數校驗的處理有關系?
大濕哥:對呀!是不是覺得咱們專案上 Controller 的代碼特清爽,
小學妹:嗯嗯,很干凈,完全沒有我在學校寫的專案那一大坨校驗的代碼,大濕哥能給我講講是怎么一回事嗎?
大濕哥:好吧!這里是利用了 Bean Validation 的技巧,下面我來詳細講講,

API 是每個 Web 專案中必不可少的部分,后端開發人員除了要處理大量的 CRUD 邏輯之外,介面的引數校驗與回應格式的規范處理也都占用了大量的精力,
在接下來的幾篇文章中,我們將介紹 API 撰寫的實戰技巧,讓從請求到回應的介面撰寫更加優雅、高效,
這篇我們來討論介面請求引數校驗,
介面常規校驗案例
我們來定義一個用戶物件 - UserDTO,包含用戶名、密碼、性別及地址,地址物件 - AddressDTO,包含省份、城市、詳細地址,
用戶物件的欄位有如下約束:
- 用戶名:
- 用戶賬號不能為空
- 賬號長度必須是6-11個字符
- 密碼:
- 密碼長度必須是6-16個字符
- 性別:
- 性別只能為 0:未知,1:男,2:女
- 地址:
- 地址資訊不能為空
UserDTO
public class UserDTO {
/**
* 校驗規則:
*
* 1. 用戶賬號不能為空
* 2. 賬號長度必須是6-11個字符
*/
private String name;
/**
* 校驗規則:
* 1. 密碼長度必須是6-16個字符
*/
private String password;
/**
* 校驗規則:
*
* 1. 性別只能為 0:未知,1:男,2:女"
*/
private int sex;
/**
* 校驗規則:
*
* 1. 地址資訊不能為空
*/
private AddressDTO address;
// 省略 Getter/Setter
}
AddressDTO
public class AddressDTO {
private String province;
private String city;
private String detail;
// 省略 Getter/Setter
}
UserController
@RestController
@RequestMapping("/users")
public class UserController {
@PostMapping("/create")
public UserDTO create(@RequestBody UserDTO userDTO) {
if (userDTO == null) {
// 此為示例代碼,正式專案中一般不使用 System.out.println 列印日志
System.out.println("用戶資訊不能為空");
return null;
}
// 校驗用戶賬戶
String name = userDTO.getName();
if (name == null || name.trim() == "") {
System.out.println("用戶賬號不能為空");
return null;
} else {
int len = name.trim().length();
if (len < 6 || len > 11) {
System.out.println("密碼長度必須是6-11個字符");
return null;
}
}
// 校驗密碼,抽出一個方法,與校驗用戶賬戶的代碼做比較
if (validatePassword(userDTO) == null) {
return null;
}
// 校驗性別
int sex = userDTO.getSex();
if (sex < 0 || sex > 2) {
System.out.println("性別只能為 0:未知,1:男,2:女");
return null;
}
// 校驗地址
validateAddress(userDTO.getAddress());
// 校驗完成后,請求的用戶資訊有效,開始處理用戶插入等邏輯,操作成功以后回應,
return userDTO;
}
// 校驗地址,通過拋出例外的方式來處理
private void validateAddress(AddressDTO addressDTO) {
if (addressDTO == null) {
// 也可以通過拋出例外來處理
throw new RuntimeException("地址資訊不能為空");
}
validateAddressField(addressDTO.getProvince(), "所在省份不能為空");
validateAddressField(addressDTO.getCity(), "所在城市不能為空");
validateAddressField(addressDTO.getDetail(), "詳細地址不能為空");
}
// 校驗地址中的每個欄位,并回傳對應的資訊
private void validateAddressField(String field, String msg) {
if (field == null || field.equals("")) {
throw new RuntimeException(msg);
}
}
// 將校驗密碼的操作抽取到一個方法中
private UserDTO validatePassword(@RequestBody UserDTO userDTO) {
String password = userDTO.getPassword();
if (password == null || password.trim() == "") {
System.out.println("用戶密碼不能為空");
return null;
} else {
int len = password.trim().length();
if (len < 6 || len > 16) {
System.out.println("賬號長度必須是6-16個字符");
return null;
}
}
return userDTO;
}
}
在 UserController 中,我們定義了創建用戶的介面 /users/create,在正式開始業務邏輯處理之前,為了保證接收到的引數有效,我們根據規則撰寫了大量的校驗代碼,即使我們可以采取抽取方法等重構手段進行復用,但依然需要對校驗規則勞心勞力,
那有沒有什么技巧,能夠避免撰寫這大量的引數校驗代碼呢?
Bean Validation 規范與其實作
上面問題的答案當然是:有!
實際上,Java 早在 2009 年就提出了 Bean Validation 規范,該規范定義的是一個運行時的資料驗證框架,在驗證之后驗證的錯誤資訊會被馬上回傳,并且已經歷經 JSR303、JSR349、JSR380 三次標準的制定,發展到了 2.0,
JSR 規范提案只是提供了規范,并沒有提供具體的實作,具體實作框架有默認的 javax.validation.api,以及 hibernate-validator,目前絕大多使用 hibernate-validator,
javax.validation.api
Java 在 2009 年的 JAVAEE 6 中發布了 JSR303 以及 javax 下的 validation 包內容,這項作業的主要目標是為 java 應用程式開發人員提供 基于 java 物件的 約束(constraints)宣告和對約束的驗證工具(validator),以及約束元資料存盤庫和查詢 API,以及默認實作,
Java8 開始,Java EE 改名為 Jakarta EE,注意 javax.validation 相關的包移動到了 jakarta.validation 的包下,所以大家看不同的版本的時候,會發現以前的版本包在 javax.validation 包下,Java 8之后在 jakarta.validation,
hibernate-validator
hibernate-validator 框架是另外一個針對 Bean Validation 規范的實作,它提供了 JSR 380 規范中所有內置 constraint 的實作,除此之外還有一些附加的 constraint,
使用 validator 進行請求引數校驗實戰
那 Spring Boot 專案中,Bean Validation 的實作框架怎么優雅地解決請求引數校驗問題呢?
接下來,我們開始實戰,我們將繼續采用「介面常規校驗案例」章節中的 UserDTO、AddressDTO,欄位的約束一樣,
新建 Spring Boot 專案,引入 spring-boot-start-web 依賴,Spring Boot 2.3.0 之后版本還需要引入 hibernate-validator,之前的版本已經包含 ,
校驗 @RequestBody 注解的引數
要校驗使用 @RequestBody 注解的引數,需要 2 個步驟:
- 對引數物件的欄位使用約束注解進行標注
- 在介面中對要校驗的引數物件標注
@Valid或者@Validated
使用約束注解對欄位進行標注
UserDTO
public class UserDTO {
@NotBlank(message = "用戶賬號不能為空")
@Size(min = 6, max = 11, message = "賬號長度必須是6-11個字符")
private String name;
@Size(min = 6, max = 16, message = "密碼長度必須是6-16個字符")
private String password;
@Range(min = 0, max = 2, message = "性別只能為 0:未知,1:男,2:女")
private int sex;
@NotNull(message = "地址資訊不能為空")
@Valid
private AddressDTO address;
// 省略 Getter/Setter
}
AddressDTO
public class AddressDTO {
@NotBlank(message = "所在省份不能為空")
private String province;
@NotBlank(message = "所在城市不能為空")
private String city;
@NotBlank(message = "詳細地址不能為空")
private String detail;
// 省略 Getter/Setter
}
可以看到,我們在需要校驗的欄位上使用 @NotNull、@Size、@Range 等約束注解進行了標注,在 AddressDTO 上還使用了 @Valid,并且注解中定義了 message 等資訊,
為物件型別引數添加 @Validated
現在再來看 UserController 中新建用戶介面的處理(注意:這里是通過 Content-Type: application/json 提交的,請求引數需要在 @RequestBody 中獲取),我們在需要校驗的 UserDTO 引數前添加 @Validated 注解,省略掉新增用戶的邏輯之后,沒有其他的顯式校驗的代碼,
/**
* 創建用戶,通過 Content-Type: application/json 提交
*
* Validator 校驗失敗將拋出 {@link MethodArgumentNotValidException}
*
* @param userDTO
* @return
*/
@PostMapping("/create-in-request-body")
public UserDTO createInRequestBody(@Validated @RequestBody UserDTO userDTO) {
// 通過 Validator 校驗引數,開始處理用戶插入等邏輯,操作成功以后回應
return userDTO;
}
驗證校驗結果
啟動 Spring Boot 應用,用 Postman 呼叫請求,觀察結果,

輸入不符合要求的欄位后,服務器回傳了錯誤的結果,(經試驗:Spring Boot 2.1.4.RELEASE 版本和 Spring Boot 2.3.3.RELEASE 版本輸出結果不一樣,前者輸出還包含 errors 展示具體每個不符合校驗規則的明細,)

在 Idea 的 Console 中可以看到如下日志,這說明不符合校驗規則的引數已經被驗證,
Resolved [org.springframework.web.bind.MethodArgumentNotValidException: Validation failed for argument [0] in public io.ron.demo.validator.use.dto.UserDTO io.ron.demo.validator.use.controller.UserController.createInRequestBody(io.ron.demo.validator.use.dto.UserDTO) with 3 errors: [Field error in object 'userDTO' on field 'password': rejected value [123]; codes [Size.userDTO.password,Size.password,Size.java.lang.String,Size]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [userDTO.password,password]; arguments []; default message [password],16,6]; default message [密碼長度必須是6-16個字符]] [Field error in object 'userDTO' on field 'name': rejected value [lang1]; codes [Size.userDTO.name,Size.name,Size.java.lang.String,Size]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [userDTO.name,name]; arguments []; default message [name],11,6]; default message [賬號長度必須是6-11個字符]] [Field error in object 'userDTO' on field 'sex': rejected value [3]; codes [Range.userDTO.sex,Range.sex,Range.int,Range]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [userDTO.sex,sex]; arguments []; default message [sex],2,0]; default message [性別只能為 0:未知,1:男,2:女]] ]
如果請求引數都滿足條件,則能正確回應結果,
校驗不使用 @RequestBody 注解的物件
有時我們也會撰寫這樣的介面,介面方法中的物件型別引數不使用 @RequestBody 注解,使用 @RequestBody 注解的物件型別引數需要明確以 Content-Type: application/json 上傳,而這種寫法可以以 Content-Type: application/x-www-form-urlencoded 上傳,
這樣撰寫介面,校驗方法與被 @RequestBody 注解的物件引數一樣,
驗證校驗結果

在 Idea 的 Console 中可以看到如下日志:
2020-09-18 17:56:05.191 WARN 9734 --- [nio-9001-exec-9] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 2 errors
Field error in object 'userDTO' on field 'name': rejected value [12345]; codes [Size.userDTO.name,Size.name,Size.java.lang.String,Size]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [userDTO.name,name]; arguments []; default message [name],11,6]; default message [賬號長度必須是6-11個字符]
Field error in object 'userDTO' on field 'address.detail': rejected value [ ]; codes [NotBlank.userDTO.address.detail,NotBlank.address.detail,NotBlank.detail,NotBlank.java.lang.String,NotBlank]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [userDTO.address.detail,address.detail]; arguments []; default message [address.detail]]; default message [詳細地址不能為空]]
請注意日志中的例外型別與 @RequestBody 注解的校驗例外的區別,
這里報的例外型別是:
org.springframework.validation.BindException,而上一節中報的例外型別是:
org.springframework.web.bind.MethodArgumentNotValidException,在下一節中的情形,報的例外則是:
javax.validation.ConstraintViolationException,例外的處理我們將在下一篇文章中說明,請關注我的公眾號:精進Java(ID:craft4j),第一時間獲取知識動態,
校驗 @PathVariable 與 @RequestParam 注解的引數
在真實專案中,不是所有的介面都接受物件型別的引數,如分頁介面中的頁碼會使用 @RequestParam 注解;Restful 風格的介面會通過 @PathVariable 來獲取資源 ID 等,這些引數無法通過上面的方法被 validator 校驗,
要校驗 @PathVariable 與 @RequestParam 注解的引數,需要 2 個步驟:
- 在要校驗的介面類上標注
@Validated注解 - 在簡單型別引數前標注
@PathVariable或@RequestParam
/**
* 測驗 @PathVariable 引數的校驗
*
* Validator 校驗失敗將拋出 {@link ConstraintViolationException}
*
* @param id
* @return
*/
@GetMapping("/user/{id}")
public UserDTO retrieve(@PathVariable("id") @Min(value = https://www.cnblogs.com/fatfoo/archive/2020/11/04/10, message ="id 必須大于 10") Long id) {
return buildUserDTO("lfy", "qwerty", 1);
}
/**
* 測驗 @RequestParam 引數校驗
*
* 在方法上加 @Validated 無法校驗 @RequestParam 與 @PathVariable
*
* 必須在類上 @Validated
*
* Validator 校驗失敗將拋出 {@link ConstraintViolationException}
*
* @param name
* @param password
* @param sex
* @return
*/
// @Validated
@GetMapping("/validate")
public UserDTO validate(@NotNull @Size(min = 6, max = 11, message = "賬號長度必須是6-11個字符") @RequestParam("name") String name,
@RequestParam("password") @Size(min = 6, max = 16, message = "密碼長度必須是6-16個字符") String password,
@RequestParam("sex") @Range(min = 0, max = 2, message = "性別只能為 0:未知,1:男,2:女") int sex) {
return buildUserDTO(name, password, sex);
}
private UserDTO buildUserDTO(String name, String password, int sex) {
UserDTO userDTO = new UserDTO();
userDTO.setName(name);
userDTO.setPassword(password);
userDTO.setSex(sex);
return userDTO;
}
驗證 @PathVariable 校驗結果
輸入小于 10 的 id,結果如下:

Idea 中 Console 報錯誤日志如下:
2020-09-18 17:23:55.744 ERROR 9734 --- [nio-9001-exec-7] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is javax.validation.ConstraintViolationException: retrieve.id: id 必須大于 10] with root cause
javax.validation.ConstraintViolationException: retrieve.id: id 必須大于 10
at org.springframework.validation.beanvalidation.MethodValidationInterceptor.invoke(MethodValidationInterceptor.java:116) ~[spring-context-5.2.8.RELEASE.jar:5.2.8.RELEASE]
......
驗證 @RequestParam 校驗結果
輸入不滿足要求的引數 name 和 password

Idea 中 Console 報錯誤日志如下:
2020-09-18 17:37:51.875 ERROR 9734 --- [nio-9001-exec-8] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is javax.validation.ConstraintViolationException: validate.password: 密碼長度必須是6-16個字符, validate.name: 賬號長度必須是6-11個字符] with root cause
javax.validation.ConstraintViolationException: validate.password: 密碼長度必須是6-16個字符, validate.name: 賬號長度必須是6-11個字符
at org.springframework.validation.beanvalidation.MethodValidationInterceptor.invoke(MethodValidationInterceptor.java:116) ~[spring-context-5.2.8.RELEASE.jar:5.2.8.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) ~[spring-aop-5.2.8.RELEASE.jar:5.2.8.RELEASE]
......
分組校驗
還有這樣的場景,如在新建用戶的介面中,用戶的 ID 欄位為空;而在更新用戶的介面中,用戶的 ID 欄位則要求是必填,針對同一個用戶物體物件,我們可以利用 validator 提供的分組校驗,
分組校驗的步驟如下:
- 定義分組介面,
- 對欄位使用約束注解進行標注,使用 groups 引數進行分組,
- 用
@Validated標識引數,并設定 groups 引數,
普通分組
Update:我們定義一個 Update 分組介面
public interface Update {
}
UserDTO:對欄位上的約束注解添加 groups 引數,下面對 id 的 @NotNull 添加了 Update 分組,對 name 欄位的 @NotBlank 添加了 Update 分組及 validator 的默認 Default 分組,
@NotNull(message = "用戶ID不能為空", groups = { Update.class })
private Long id;
@NotBlank(message = "用戶賬號不能為空", groups = { Update.class, Default.class })
@Size(min = 6, max = 11, message = "賬號長度必須是6-11個字符")
private String name;
UserController:在更新用戶介面中對引數使用 @Validated 注解并設定 Update 分組,
@PutMapping("/update")
public UserDTO update(@Validated({Update.class}) @RequestBoy UserDTO userDTO) {
// 通過 Validator 校驗引數,開始處理用戶插入等邏輯,操作成功以后回應
return userDTO;
}
這里將只會對設定了分組為 Update 的約束進行校驗,當 id 為慷訓者 name 為慷訓者空白的時候會報約束錯誤,當 id 與 name 均不為空時,即使 name 的長度不在 6-11 個字符之間,也不會校驗,
組序列
除了按組指定是否驗證之外,還可以指定組的驗證順序,前面組驗證不通過的,后面組將不進行驗證,
OrderedGroup:定義了校驗組的順序,Update 優先于 Default,
@GroupSequence({ Update.class, Default.class })
public interface OrderedGroup {
}
UserController:在介面引數中 @Validated 注解設定引數 OrderedGroup.class,
@PostMapping("/ordered")
public UserDTO ordered(@Validated({OrderedGroup.class}) @RequestBody UserDTO userDTO) {
// 通過 Validator 校驗引數,開始處理用戶插入等邏輯,操作成功以后回應
return userDTO;
}
與普通分組中的案例結果不同,這里會優先校驗 id 是否為慷訓者 name 是否為慷訓者空白,即 Update 分組的約束;Update 分組約束滿足之后,還會進行其他引數的校驗,因為其他引數都默認為 Default 分組,
hibernate-validator 的校驗模式
從上面的案例中,細心的你可能已經發現了這樣的現象:所有的引數都做了校驗,實際上只要有一個引數校驗不通過,我們就可以回應給用戶,而 hibernate-validator 可以支持兩種校驗模式:
- 普通模式,默認是這種模式,該模式會校驗完所有的屬性,然后回傳所有的驗證失敗資訊
- 快速失敗回傳模式,這種模式下只要有一個引數校驗失敗就立即回傳
開啟快速失敗回傳模式
@Configuration
public class ValidatorConfig {
@Value("${hibernate.validator.fail_fast:false}")
private boolean failfast;
@Bean
public Validator validator() {
ValidatorFactory validatorFactory = Validation.byProvider(HibernateValidator.class)
.configure()
// failFast 為 true 時,只要出現校驗失敗的情況,就立即結束校驗,不再進行后續的校驗,
.failFast(failfast)
.buildValidatorFactory();
return validatorFactory.getValidator();
}
@Bean
public MethodValidationPostProcessor methodValidationPostProcessor() {
MethodValidationPostProcessor postProcessor = new MethodValidationPostProcessor();
// 設定 validator 模式為快速失敗回傳
postProcessor.setValidator(validator());
return postProcessor;
}
}
我們需要對 MethodValidationPostProcessor 設定開啟快失敗回傳模式的 validator,而 validator 則只需設定 hibernate.validator.fail_fast 屬性為 true,
再次運行 Spring Boot 專案,進行測驗,我們會發現現在只要有一個引數校驗失敗,就立即回傳了,
自定義約束實作
vaidation-api 與 hibernate-validator 提供的約束注解已經能夠滿足我們絕大多數的引數校驗要求,但有時我們可能也需要使用自定義的 Validator 校驗器,
自定義約束實作與使用包含如下步驟:
- 自定義約束注解
- 實作
ConstraintValidator來自定義校驗邏輯
通用列舉型別約束
我們以自定義一個相對通用的列舉型別約束來演示,
自定義 @EnumValue 列舉指約束注解
enumClass 標識欄位取值對應哪個列舉型別,enumMethod 則是需要列舉類定義一個用于驗證取值是否有效的驗證方法,如果為空的話,我們會默認提供處理引數為整型與字串型的情況,需要在注解上使用 @Constraint(validatedBy) 來設定具體使用的校驗器,
@Target({ ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = EnumValue.EnumValidator.class)
public @interface EnumValue {
String message() default "無效的列舉值";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
Class<? extends Enum<?>> enumClass();
String enumMethod() default "";
}
撰寫 EnumValidator 來自定義校驗邏輯
class EnumValidator implements ConstraintValidator<EnumValue, Object> {
private Class<? extends Enum<?>> enumClass;
private String enumMethod;
@Override
public void initialize(EnumValue enumValue) {
enumMethod = enumValue.enumMethod();
enumClass = enumValue.enumClass();
}
@Override
public boolean isValid(Object value, ConstraintValidatorContext constraintValidatorContext) {
if (value =https://www.cnblogs.com/fatfoo/archive/2020/11/04/= null) {
return Boolean.TRUE;
}
if (enumClass == null) {
return Boolean.TRUE;
}
Class<?> valueClass = value.getClass();
if (enumMethod == null || enumMethod.equals("")) {
String valueClassName = valueClass.getCanonicalName();
// 處理引數可以轉為列舉值 ordinal 的情況
if (valueClassName.equals("java.lang.Integer")) {
return enumClass.getEnumConstants().length > (Integer) value;
}
// 處理引數為列舉名稱的情況
else if (valueClassName.equals("java.lang.String")) {
return Arrays.stream(enumClass.getEnumConstants()).anyMatch(e -> e.toString().equals(value));
}
throw new RuntimeException(String.format("A static method to valid enum value is needed in the %s class", enumClass));
}
// 列舉類自定義取值校驗
try {
Method method = enumClass.getMethod(enumMethod, valueClass);
if (!Boolean.TYPE.equals(method.getReturnType()) && !Boolean.class.equals(method.getReturnType())) {
throw new RuntimeException(String.format("%s method return is not boolean type in the %s class", enumMethod, enumClass));
}
if (!Modifier.isStatic(method.getModifiers())) {
throw new RuntimeException(String.format("%s method is not static method in the %s class", enumMethod, enumClass));
}
Boolean result = (Boolean) method.invoke(null, value);
return result == null ? false : result;
} catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
throw new RuntimeException(e);
} catch (NoSuchMethodException | SecurityException e) {
throw new RuntimeException(String.format("This %s(%s) method does not exist in the %s", enumMethod, valueClass, enumClass), e);
}
}
}
實作 ConstraintValidator 的兩個方法 initialize、isValid,一個是初始化引數的方法,另一個就是校驗邏輯的方法,
在校驗方法中,當約束注解沒有定義 enumMethod 時,我們根據傳入需要校驗的引數提供整型與字符型的兩種默認校驗,可以仔細看原始碼第 23-34 行,從 37-54 行的代碼可以看到,除開上面的 2 種情況下,列舉型別需要提供一個自定義的校驗方法,
在專案中使用
Gender:我們定義一個表示性別的列舉,這里我們撰寫了一個判斷列舉取值是否有效的靜態方法 isValid(),
public enum Gender {
UNKNOWN,
MALE,
FEMALE;
/**
* 判斷取值是否有效
*
* @param val
* @return
*/
public static boolean isValid(Integer val) {
return Gender.values().length > val;
}
}
UserDTO:給 sex 欄位的設定 @EnumValue 約束
@Range(min = 0, max = 2, message = "性別只能為 0:未知,1:男,2:女")
@EnumValue(enumClass = Gender.class)
private int sex;
接下來就是運行程式,發請求觀察校驗結果了,
總結
前面我們從一個常規校驗案例開始,說明了 Bean Validation 規范及其實作,并從實戰角度出發介紹了各種場景下的校驗,包括:
- 使用
@RequestBody和不使用@RequestBody注解的物件型別引數 - 使用
@RequestParam和@PathVariable注解的簡單型別引數 - 分組校驗
- 快速失敗回傳校驗模式
- 自定義約束校驗
總體而言,使用 validator 能夠極大的方便請求引數的校驗,簡化校驗相關的實作代碼,但是,細心的讀者也發現了,本文中所有的介面當有引數校驗失敗時,都是報了例外,回傳的回應中直接報 400 或者 500 的錯誤,回應不直觀,不規范,給到前端也無法方便高效的處理,
在接下來的文章中,我將繼續為大家帶來全域例外處理、統一回應結構的知識與實戰,
文中涉及的代碼已經開源在我的 Github 倉庫 ron-point 中,如果覺得不錯請點個 star,歡迎一起討論和交流,
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/202423.html
標籤:其他
下一篇:pycharm進行代碼更新比較
