Controller 中注解使用

接受參數(shù)的幾種傳輸方式以及幾種注解：

在上一篇中，我們使用了JDBC鏈接數(shù)據(jù)庫(kù)，完成了簡(jiǎn)單的后端開(kāi)發(fā)。但正如我在上文中拋出的問(wèn)題，我們能不能更好的優(yōu)化我們?cè)贑ontroller中接受參數(shù)的方式呢？這一篇中我們就來(lái)聊一聊怎么更有效的接收J(rèn)son參數(shù)。

傳輸參數(shù)的幾種Method

在定義一個(gè)Rest接口時(shí)，我們通常會(huì)使用GET，POST，PUT，DELETE幾種方式來(lái)完成我們所需要進(jìn)行CRUD的一些操作，我們?cè)谶@里羅列和教大家在實(shí)際開(kāi)發(fā)中的使用，一些基本概念我們就不再贅述，例如使用POST的優(yōu)缺點(diǎn)，可使用參數(shù)的大小限制等地：

• GET：一般用于查詢(xún)數(shù)據(jù)，不辦函數(shù)據(jù)的更新以及插入操作。由于明文傳輸?shù)年P(guān)系，我們一般用來(lái)獲取一些無(wú)關(guān)用戶(hù)的信息。
• POST：一般用于數(shù)據(jù)的插入操作，也是使用最多的傳輸方式，但是在H5調(diào)用時(shí)會(huì)有跨域的問(wèn)題，一般使用JSONP來(lái)解決。
• PUT：我們使用PUT方式來(lái)對(duì)數(shù)據(jù)進(jìn)行更新操作。
• DELETE：用于數(shù)據(jù)刪除，注意在數(shù)據(jù)庫(kù)內(nèi)是邏輯刪除（改變數(shù)據(jù)狀態(tài)，用戶(hù)不再查詢(xún)得到，但還保留在數(shù)據(jù)庫(kù)內(nèi)）還是物理刪除（真刪了）。

以上是很標(biāo)準(zhǔn)的REST風(fēng)格的接口形式，其實(shí)我們可以進(jìn)源碼看到，他們只不過(guò)封裝了

@RequestMapping(
method = {RequestMethod.POST}
)

這個(gè)方法，和我們使用以前的@RequestMapping后寫(xiě)參數(shù)是一致的。但是在實(shí)際開(kāi)發(fā)中我們一般是前后端分離開(kāi)發(fā)的，像IOS以及ANDROID開(kāi)發(fā)他們會(huì)固定使用同一套模版進(jìn)行傳輸，這時(shí)可能你所有的接口都會(huì)是POST方法。這需要你在開(kāi)發(fā)中事先和前端人員進(jìn)行約定，這時(shí)接口文檔就會(huì)變得非常重要了。方法，入?yún)?，出參，?bào)錯(cuò)信息都必須清晰的描述在接口文檔中，所以不要小看編寫(xiě)文檔的能力哦。當(dāng)然，SpringBoot也為我們提供了強(qiáng)大的API模版，例如swagger。不過(guò)使用swagger也不是一勞永逸的，關(guān)于swagger，我們之后再聊。

獲取參數(shù)的幾種常用注解

在上一篇中我們使用了幾種注解來(lái)獲取參數(shù)，例如@RequestParam，@PathVariable，@RequestBody。那我們現(xiàn)在來(lái)逐一看一下這些注解我們?cè)撊绾问褂谩?/p>

• @PathVariable：一般我們使用URI template樣式映射使用，即url/{param}這種形式，也就是一般我們使用的GET，DELETE，PUT方法會(huì)使用到的，我們可以獲取URL后所跟的參數(shù)。
• @RequestParam：一般我們使用該注解來(lái)獲取多個(gè)參數(shù)，在（）內(nèi)寫(xiě)入需要獲取參數(shù)的參數(shù)名即可，一般在PUT，POST中比較常用。
• @RequestBody：該注解和@RequestParam殊途同歸，我們使用該注解將所有參數(shù)轉(zhuǎn)換，在代碼部分在一個(gè)個(gè)取出來(lái)，也是目前我使用到最多的注解來(lái)獲取參數(shù)（因?yàn)榍岸瞬辉敢庖粋€(gè)一個(gè)接口的調(diào)試）例如下代碼：

@PostMapping("/createUserByMap")
public void createUserByMap(@RequestBody Map<String,Object> reqMap){
    String tel = reqMap.get("tel").toString();
    String pwd = reqMap.get("pwd").toString();
    userService.createUser(tel,pwd);
}

當(dāng)然，我們獲取參數(shù)不僅僅只有上面所提到的那些，還有@RequestHeader來(lái)獲取頭信息里的值，@CookieValue來(lái)獲取Cookie值等等。在這，我也僅僅說(shuō)明一些較常用的取值方法而已。

使用對(duì)象直接獲取參數(shù)

當(dāng)我們掌握以上幾種方式來(lái)獲取參數(shù)時(shí)，看似已經(jīng)毫無(wú)問(wèn)題，其實(shí)還是有的，如果我們的入?yún)⑹侄嗄?？一百幾十個(gè)參數(shù)，你是血一百幾十個(gè)@RequestParam，還是@RequestBody之后取一百幾十個(gè)次呢？，明顯這些做法都十分麻煩，代碼太多，關(guān)鍵是我們懶啊……所以，我們也可以通過(guò)POJO來(lái)直接獲取參數(shù)，之后通過(guò)GET方法直接把需要的參數(shù)取出就好。

我們來(lái)將上一次的方法給改變下：

/**
 * 添加用戶(hù)2
 * @param userInfo
 */
@PostMapping("/createUser2")
public void createUser2(UserInfo userInfo){
    userService.createUser(userInfo.getTel(),userInfo.getPassWord());
}

我們來(lái)測(cè)試一下，發(fā)現(xiàn)失敗了，通過(guò)錯(cuò)誤信息，我們發(fā)現(xiàn)SQL提示password為null，也就是說(shuō)我們沒(méi)有獲取到pwd這個(gè)參數(shù)，這是因?yàn)槿绻褂脤?duì)象接受參數(shù)，那參數(shù)名必須喝對(duì)象的屬性名保持一致。

我們修改參數(shù)名為passWord后可以發(fā)現(xiàn)，數(shù)據(jù)可以爭(zhēng)產(chǎn)的進(jìn)行插入了。

使用@Valid對(duì)參數(shù)進(jìn)行校驗(yàn)

在使用對(duì)象進(jìn)行參數(shù)接收時(shí)，我們可以對(duì)參數(shù)進(jìn)行校驗(yàn)，假設(shè)我們需要用戶(hù)輸入的密碼是整數(shù)型且在000000至999999之間的數(shù)值，我們可以對(duì)屬性passWord加上如下注解：

@Max(value = 999999,message = "超過(guò)最大數(shù)值")
@Min(value = 000000,message = "密碼設(shè)定不正確")
private String passWord;

這里舉的列子并不十分合適，請(qǐng)注意。我們只是針對(duì)表單驗(yàn)證進(jìn)行講解，在實(shí)際開(kāi)發(fā)處理中要選擇合適的操作。message是反回的提示默認(rèn)信息。
在controller中我們改寫(xiě)一下，將返回值設(shè)為String，讓我們可以看到報(bào)錯(cuò)信息。

然后我們給對(duì)象加入@Valid注解，并在參數(shù)中加入BindingResult來(lái)獲取錯(cuò)誤信息。在邏輯處理中我們判斷BindingResult知否含有錯(cuò)誤信息，如果有錯(cuò)誤信息，則直接返回錯(cuò)誤信息。

/**
 * 添加用戶(hù)2
 * @param userInfo
 */
@PostMapping("/createUser2")
public String createUser2(@Valid UserInfo userInfo, BindingResult bindingResult){
    if (bindingResult.hasErrors()){
        return bindingResult.getFieldError().getDefaultMessage();
    }
    userService.createUser(userInfo.getTel(),userInfo.getPassWord());
    return "OK";
}

我們繼續(xù)通過(guò)POSTMAN來(lái)測(cè)試一下，首先我們傳入-10000來(lái)設(shè)定密碼，發(fā)現(xiàn)提示錯(cuò)誤密碼設(shè)定不正確：

發(fā)現(xiàn)無(wú)法完成用戶(hù)注冊(cè)，我們繼續(xù)通過(guò)添加密碼為1000000來(lái)設(shè)定密碼，發(fā)現(xiàn)提示錯(cuò)誤信息超過(guò)最大數(shù)值：

以上就是我們通過(guò)簡(jiǎn)單的表單驗(yàn)證來(lái)預(yù)防一些惡意數(shù)據(jù)的侵入。不知道你有沒(méi)有掌握呢？當(dāng)然，我們對(duì)于數(shù)據(jù)的驗(yàn)證不僅僅只有表單驗(yàn)證，我們一般通過(guò)數(shù)據(jù)簽名的方式來(lái)驗(yàn)證一個(gè)請(qǐng)求是否合法，也可能是將整個(gè)參數(shù)進(jìn)行對(duì)稱(chēng)加密后進(jìn)行傳輸以保證數(shù)據(jù)不被明文抓包。

那以上所說(shuō)的處理模式就會(huì)用到Spring為我們提供的另一個(gè)強(qiáng)大的功能，也是我們使用Spring系列框架中不可或缺的一部分，AOP，切面編程。我們之前所說(shuō)的統(tǒng)一報(bào)錯(cuò)處理也是使用的AOP功能進(jìn)行處理的，那關(guān)于A(yíng)OP，我們下周再聊。（原諒我懶得要死，這篇文章也是被迫趕工的……捂臉，逃……）(???)?

以上所有的代碼我已經(jīng)上傳到GitHub

round1-springboot

如果心急的小伙伴也可以去clone我已經(jīng)完成的項(xiàng)目，這個(gè)項(xiàng)目中把一些常用功能都寫(xiě)了，并且都寫(xiě)注釋啦?。?！

MySpringBoot

總結(jié)

到此這篇關(guān)于SpringBoot開(kāi)發(fā)詳解之Controller接收參數(shù)及參數(shù)校驗(yàn)的文章就介紹到這了,更多相關(guān)SpringBoot Controller接收參數(shù)及校驗(yàn)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論