您好,登錄后才能下訂單哦!
這篇文章主要講解了“Spring Boot 2.x中JSR-303實(shí)現(xiàn)請求參數(shù)校驗(yàn)的方法”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“Spring Boot 2.x中JSR-303實(shí)現(xiàn)請求參數(shù)校驗(yàn)的方法”吧!
請求參數(shù)的校驗(yàn)是很多新手開發(fā)非常容易犯錯(cuò),或存在較多改進(jìn)點(diǎn)的常見場景。比較常見的問題主要表現(xiàn)在以下幾個(gè)方面:
僅依靠前端框架解決參數(shù)校驗(yàn),缺失服務(wù)端的校驗(yàn)。這種情況常見于需要同時(shí)開發(fā)前后端的時(shí)候,雖然程序的正常使用不會(huì)有問題,但是開發(fā)者忽略了非正常操作。比如繞過前端程序,直接模擬客戶端請求,這時(shí)候就會(huì)突然在前端預(yù)設(shè)的各種限制,直擊各種數(shù)據(jù)訪問接口,使得我們的系統(tǒng)存在安全隱患。
大量地使用if/else
語句嵌套實(shí)現(xiàn),校驗(yàn)邏輯晦澀難通,不利于長期維護(hù)。
所以,針對上面的問題,建議服務(wù)端開發(fā)在實(shí)現(xiàn)接口的時(shí)候,對于請求參數(shù)必須要有服務(wù)端校驗(yàn)以保障數(shù)據(jù)安全與穩(wěn)定的系統(tǒng)運(yùn)行。同時(shí),對于參數(shù)的校驗(yàn)實(shí)現(xiàn)需要足夠優(yōu)雅,要滿足邏輯易讀、易維護(hù)的基本特點(diǎn)。
接下來,我們就在本篇教程中詳細(xì)說說,如何優(yōu)雅地實(shí)現(xiàn)Spring Boot服務(wù)端的請求參數(shù)校驗(yàn)。
在開始動(dòng)手實(shí)踐之前,我們先了解一下接下來我們將使用的一項(xiàng)標(biāo)準(zhǔn)規(guī)范:JSR-303
什么是JSR?
JSR是Java Specification Requests的縮寫,意思是Java 規(guī)范提案。是指向JCP(Java Community Process)提出新增一個(gè)標(biāo)準(zhǔn)化技術(shù)規(guī)范的正式請求。任何人都可以提交JSR,以向Java平臺增添新的API和服務(wù)。JSR已成為Java界的一個(gè)重要標(biāo)準(zhǔn)。
JSR-303定義的是什么標(biāo)準(zhǔn)?
JSR-303 是JAVA EE 6 中的一項(xiàng)子規(guī)范,叫做Bean Validation,Hibernate Validator 是 Bean Validation 的參考實(shí)現(xiàn) . Hibernate Validator 提供了 JSR 303 規(guī)范中所有內(nèi)置 constraint 的實(shí)現(xiàn),除此之外還有一些附加的 constraint。
Bean Validation中內(nèi)置的constraint
Hibernate Validator附加的constraint
在JSR-303的標(biāo)準(zhǔn)之下,我們可以通過上面這些注解,優(yōu)雅的定義各個(gè)請求參數(shù)的校驗(yàn)。更多關(guān)于JSR的內(nèi)容可以參與官方文檔或參考資料中的引文[1]。
已經(jīng)了解了JSR-303之后,接下來我們就來嘗試一下,基于此規(guī)范如何實(shí)現(xiàn)參數(shù)的校驗(yàn)!
讀者可以拿任何一個(gè)使用Spring Boot 2.x構(gòu)建的提供RESTful API的項(xiàng)目作為基礎(chǔ)。也可以使用Spring Boot 2.x基礎(chǔ)教程:使用Swagger2構(gòu)建強(qiáng)大的API文檔中構(gòu)建的實(shí)驗(yàn)工程作為基礎(chǔ),您可以通過下面?zhèn)}庫中的chapter2-2
目錄取得:
Github:https://github.com/dyc87112/SpringBoot-Learning/tree/2.x
Gitee:https://gitee.com/didispace/SpringBoot-Learning/tree/2.x
當(dāng)然,您也可以根據(jù)前文再構(gòu)建一個(gè)作為復(fù)習(xí),也是完全沒有問題的。
我們先來做一個(gè)簡單的例子,比如:定義字段不能為Null
。只需要兩步
第一步:在要校驗(yàn)的字段上添加上@NotNull
注解,具體如下:
@Data @ApiModel(description="用戶實(shí)體") public class User { @ApiModelProperty("用戶編號") private Long id; @NotNull @ApiModelProperty("用戶姓名") private String name; @NotNull @ApiModelProperty("用戶年齡") private Integer age; }
第二步:在需要校驗(yàn)的參數(shù)實(shí)體前添加@Valid
注解,具體如下:
@PostMapping("/") @ApiOperation(value = "創(chuàng)建用戶", notes = "根據(jù)User對象創(chuàng)建用戶") public String postUser(@Valid @RequestBody User user) { users.put(user.getId(), user); return "success"; }
完成上面配置之后,啟動(dòng)應(yīng)用,并用POST請求訪問localhost:8080/users/
接口,body使用一個(gè)空對象,{}
。你可以用Postman等測試工具發(fā)起,也可以使用curl發(fā)起,比如這樣:
curl -X POST \ http://localhost:8080/users/ \ -H 'Content-Type: application/json' \ -H 'Postman-Token: 72745d04-caa5-44a1-be84-ba9c115f4dfb' \ -H 'cache-control: no-cache' \ -d '{ }'
不出意外,你可以得到如下結(jié)果:
{ "timestamp": "2019-10-05T05:45:19.221+0000", "status": 400, "error": "Bad Request", "errors": [ { "codes": [ "NotNull.user.age", "NotNull.age", "NotNull.java.lang.Integer", "NotNull" ], "arguments": [ { "codes": [ "user.age", "age" ], "arguments": null, "defaultMessage": "age", "code": "age" } ], "defaultMessage": "不能為null", "objectName": "user", "field": "age", "rejectedValue": null, "bindingFailure": false, "code": "NotNull" }, { "codes": [ "NotNull.user.name", "NotNull.name", "NotNull.java.lang.String", "NotNull" ], "arguments": [ { "codes": [ "user.name", "name" ], "arguments": null, "defaultMessage": "name", "code": "name" } ], "defaultMessage": "不能為null", "objectName": "user", "field": "name", "rejectedValue": null, "bindingFailure": false, "code": "NotNull" } ], "message": "Validation failed for object='user'. Error count: 2", "path": "/users/" }
其中返回內(nèi)容的各參數(shù)含義如下:
timestamp
:請求時(shí)間
status
:HTTP返回的狀態(tài)碼,這里返回400,即:請求無效、錯(cuò)誤的請求,通常參數(shù)校驗(yàn)不通過均為400
error
:HTTP返回的錯(cuò)誤描述,這里對應(yīng)的就是400狀態(tài)的錯(cuò)誤描述:Bad Request
errors
:具體錯(cuò)誤原因,是一個(gè)數(shù)組類型;因?yàn)殄e(cuò)誤校驗(yàn)可能存在多個(gè)字段的錯(cuò)誤,比如這里因?yàn)槎x了兩個(gè)參數(shù)不能為Null
,所以存在兩條錯(cuò)誤記錄信息
message
:概要錯(cuò)誤消息,返回內(nèi)容中很容易可以知道,這里的錯(cuò)誤原因是對user對象的校驗(yàn)失敗,其中錯(cuò)誤數(shù)量為2
,而具體的錯(cuò)誤信息就定義在上面的errors
數(shù)組中
path
:請求路徑
請求的調(diào)用端在拿到這個(gè)規(guī)范化的錯(cuò)誤信息之后,就可以方便的解析并作出對應(yīng)的措施以完成自己的業(yè)務(wù)邏輯了。
在完成了上面的例子之后,我們還可以增加一些校驗(yàn)規(guī)則,比如:校驗(yàn)字符串的長度、校驗(yàn)數(shù)字的大小、校驗(yàn)字符串格式是否為郵箱等。下面我們就來定義一些復(fù)雜的校驗(yàn)定義,比如:
@Data @ApiModel(description="用戶實(shí)體") public class User { @ApiModelProperty("用戶編號") private Long id; @NotNull @Size(min = 2, max = 5) @ApiModelProperty("用戶姓名") private String name; @NotNull @Max(100) @Min(10) @ApiModelProperty("用戶年齡") private Integer age; @NotNull @Email @ApiModelProperty("用戶郵箱") private String email; }
發(fā)起一個(gè)可以出發(fā)name
、age
、email
都校驗(yàn)不通過的請求,比如下面這樣:
curl -X POST \ http://localhost:8080/users/ \ -H 'Content-Type: application/json' \ -H 'Postman-Token: 114db0f0-bdce-4ba5-baf6-01e5104a68a3' \ -H 'cache-control: no-cache' \ -d '{ "name": "abcdefg", "age": 8, "email": "aaaa" }'
我們將得到如下的錯(cuò)誤返回:
{ "timestamp": "2019-10-05T06:24:30.518+0000", "status": 400, "error": "Bad Request", "errors": [ { "codes": [ "Size.user.name", "Size.name", "Size.java.lang.String", "Size" ], "arguments": [ { "codes": [ "user.name", "name" ], "arguments": null, "defaultMessage": "name", "code": "name" }, 5, 2 ], "defaultMessage": "個(gè)數(shù)必須在2和5之間", "objectName": "user", "field": "name", "rejectedValue": "abcdefg", "bindingFailure": false, "code": "Size" }, { "codes": [ "Min.user.age", "Min.age", "Min.java.lang.Integer", "Min" ], "arguments": [ { "codes": [ "user.age", "age" ], "arguments": null, "defaultMessage": "age", "code": "age" }, 10 ], "defaultMessage": "最小不能小于10", "objectName": "user", "field": "age", "rejectedValue": 8, "bindingFailure": false, "code": "Min" }, { "codes": [ "Email.user.email", "Email.email", "Email.java.lang.String", "Email" ], "arguments": [ { "codes": [ "user.email", "email" ], "arguments": null, "defaultMessage": "email", "code": "email" }, [], { "defaultMessage": ".*", "codes": [ ".*" ], "arguments": null } ], "defaultMessage": "不是一個(gè)合法的電子郵件地址", "objectName": "user", "field": "email", "rejectedValue": "aaaa", "bindingFailure": false, "code": "Email" } ], "message": "Validation failed for object='user'. Error count: 3", "path": "/users/" }
從errors
數(shù)組中的各個(gè)錯(cuò)誤明細(xì)中,知道各個(gè)字段的defaultMessage
,可以看到很清晰的錯(cuò)誤描述。
可能有讀者會(huì)問了,我的接口中是定了這么多。上一篇教程中,不是還教了如何自動(dòng)生成文檔么,那么對于參數(shù)的校驗(yàn)邏輯該如何描述呢?
這里要分兩種情況,Swagger自身對JSR-303有一定的支持,但是支持的并那么完善,并沒有覆蓋所有的注解的。
比如,上面我們使用的注解是可以自動(dòng)生成的,啟動(dòng)上面我們的實(shí)驗(yàn)工程,然后訪問http://localhost:8080/swagger-ui.html
,在Models
不是,我們可以看到如下圖所示的內(nèi)容:
其中:name
和age
字段相比上一篇教程中的文檔描述,多了一些關(guān)于校驗(yàn)相關(guān)的說明;而email
字段則沒有體現(xiàn)相關(guān)校驗(yàn)說明。目前,Swagger共支持以下幾個(gè)注解:@NotNull
、@Max
、@Min
、@Size
、@Pattern
。在實(shí)際開發(fā)過程中,我們需要分情況來處理,對于Swagger支自動(dòng)生成的可以利用原生支持來產(chǎn)生,如果有部分字段無法產(chǎn)生,則可以在@ApiModelProperty
注解的描述中他,添加相應(yīng)的校驗(yàn)說明,以便于使用方查看。
當(dāng)請求參數(shù)校驗(yàn)出現(xiàn)錯(cuò)誤信息的時(shí)候,錯(cuò)誤格式可以修改嗎?
答案是肯定的。這里的錯(cuò)誤信息實(shí)際上由Spring Boot的異常處理機(jī)制統(tǒng)一組織并返回的,我們將在后面的教程中詳細(xì)介紹,Spring Boot是如何統(tǒng)一處理異常返回以及我們該如何定時(shí)異常返回。
spring-boot-starter-validation
是必須的嗎?
有讀者之前問過,看到很多教程都寫了還要引入spring-boot-starter-validation
依賴,這個(gè)依賴到底是否需要?(本篇中并沒有引入)
<dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-validation</artifactid> </dependency>
其實(shí),只需要仔細(xì)看一下spring-boot-starter-validation
依賴主要是為了引入了什么,再根據(jù)當(dāng)前自己使用的Spring Boot版本來判斷即可。實(shí)際上,spring-boot-starter-validation
依賴主要是為了引入下面這個(gè)依賴:
<dependency> <groupid>org.hibernate.validator</groupid> <artifactid>hibernate-validator</artifactid> <version>6.0.14.Final</version> <scope>compile</scope> </dependency>
我們可以看看當(dāng)前工程的依賴中是否有它,就可以判斷是否還需要額外引入。在Spring Boot 2.1版本中,該依然其實(shí)已經(jīng)包含在了spring-boot-starter-web
依賴中,并不需要額外引入,所以您在本文中找不到這一步。
本文的完整工程可以查看下面?zhèn)}庫中的chapter2-3
目錄:
Github:https://github.com/dyc87112/SpringBoot-Learning/tree/2.x
Gitee:https://gitee.com/didispace/SpringBoot-Learning/tree/2.x
感謝各位的閱讀,以上就是“Spring Boot 2.x中JSR-303實(shí)現(xiàn)請求參數(shù)校驗(yàn)的方法”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對Spring Boot 2.x中JSR-303實(shí)現(xiàn)請求參數(shù)校驗(yàn)的方法這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云,小編將為大家推送更多相關(guān)知識點(diǎn)的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。