基於params、@PathVariabl和@RequestParam的用法與區別說明

方法參數相關屬性params、@PathVariabl和@RequestParam的使用

【1】params

params：指定request中必須包含某些參數值是，才讓該方法處理。

    @RequestMapping(value = "testParamsAndHeaders", params = { "username","age!=10" })
    public String testParamsAndHeaders() {
        System.out.println("testParamsAndHeaders");
        return SUCCESS;
    }

params 隻是判斷url 或者 form data 中的參數是否復合params的定義，並不會直接綁定數據到方法的參數中！

【2】@PathVariabl

綁定路徑中的占位符參數到方法參數變量中；隻能綁定路徑中的占位符參數，且路徑中必須有參數。

無論是 GET 或者POST 隻要 URL中有參數即可！

實例如下：

• GET

Request URL:http://localhost:8080/SpringMVC-1/springmvc/testPathVariable/1

• POST

<form action="springmvc/testPathVariable/1" method="POST">
<input type="text" name="username" value=""/>
<input type="text" name="age" value=""/>
<input type="text" name="sex" value=""/>
<input type="submit" value="submit"/>
</form>

【註意】如果URL中無參數，將會出錯；如果URL有參數，但是沒有使用@PathVariabl該註解，那麼URL的參數不會默認與方法參數綁定！方法裡的參數會默認綁定表單裡面對應的參數！

後臺code

如果參數名與占位符一致，則可直接使用@PathVariable；如果不一致，則在@PathVariable( )括號內綁定占位符。

 @RequestMapping("/testPathVariable/{id}")
 public String testPathVariable(@PathVariable("id") Integer id2) {
  System.out.println("testPathVariable: " + id2);
  return SUCCESS;
 }

【3】@RequestParam

該註解相關屬性如下：

• value：參數key，可以不寫，默認為””；
• name：和value作用一樣；
• required：默認值為true，可以不寫；
• 獲取URL或者 form data 中的參數

前臺請求實例如下：

• GET

<a href="springmvc/testRequestParam?userName=tom&age=11&sex=boy" rel="external nofollow" >

• POST

<form action="springmvc/testRequestParam" method="POST">
<input type="text" name="userName" value=""/>
<input type="text" name="age" value=""/>
<input type="text" name="sex" value=""/>
<input type="submit" value="submit"/>
</form>

註意 ：

GET中的參數形式為：username=tom&age=11&sex=boy

POST中的參數形式為：以鍵值對形式保存在form data

後臺代碼示例：

	@RequestMapping(value="/regist",produces="application/json;charset=utf-8")
	@ResponseBody
	public String regist(SysUser sysUser , @RequestParam(required=true,name="sex") String sex){
		String userName = sysUser.getUserName();
		String age = sysUser.getAge();
		//...
		return "regist success";
	}

總得來說，均是鍵值對形式，與@PathVariabl中的占位符形式不同！！！

在springmvc中使用@PathVariable時，應該註意點什麼？

近來在做庫存調劑系統時，我從前臺到後臺的傳值方式，主要包括：1個，用@PathVariable或者@RequestParam從路徑取；大於一個，用於更新或者添加操作的，我用的是表單實體傳到後臺；大於一個，用於查詢的，我用的@RequestBody（好吧，我承認這個隻是我覺得好玩，但沒有多少人願意在後臺一行又一行的寫：String test=request.getParameter(“test”);吧？？？？？）

現在，主要就是想說一個從路徑取值的“坑”，而重中之重，就想說一下我更偏愛的@PathVariable（別問我為什麼，/{param}/fn.do，簡單啊）

一、使用@PathVariable的轉變過程

首先：

在盤古開天辟地時，就是一切還很混沌時，姑娘我連用@PathVariable取值都沒有取過來，還蒙圈蒙瞭一小會兒，完全不明白發生瞭什麼，因為我看著我的語法和格式，哪兒哪兒都對，但就是沒有傳過來值。我一想我原來寫/{param}/fn.do這種方式傳值的時候，也沒有問題呀，怎麼今天是見鬼瞭？？？？ 蒙圈完瞭之後，就發現端倪瞭。

請看看我怎麼寫的哈：

@RequestMapping("/dealerStock/swapOrder/{orderID}/cancelAuditThisOrder.do")
public @ResponseBody String cancelAuditThisOrder(@PathVariable("OrderID") String strOrderID）){
...
...
}

然後的然後，我就一直沒有請求到這個方法，更別談什麼有沒有取到值的問題！後來解決的時候，真想一掌拍自己腦門上！

然後：

當代碼規范審查通過後，也經過瞭測試部的一級功能業務測試以及業務部的二級業務流程測試。文檔之類的，都準備好瞭（我還能再說什麼呢，無聲的兩個呵 呵） 正要佈上去生產線的時候，老大再次審查瞭一遍代碼，審查到最後也沒個啥結果，但是，突然間看到那個@PathVariable就問瞭我兩個問題：一，如果我的ID是不連續的，這種方法還能好使嗎？比如說：HC 782981；二，是不是隻要我拿到這個請求路徑，而我隨便推測一個ID號，就能避過用戶操作別人的數據？

姑娘我再次被雷擊倒，無言以對，馬上實際驗證。結果：Yes！ 你說第一個的結果是Yes，這個我很滿意，但第二個是Yes，就很想哭瞭。 測試出結果後，就請命去幹掉這個問題瞭。

我的第一步嘗試：

添加method=RequestMethod.post，也就是說用戶不能輸入Url地址以get的形式獲取數據，隻能通過系統內部請求。

組長：你自己說，就算咱們改成瞭Post請求，你能不能訪問到？

姑娘：我能，就自己寫一個按鈕，再用post請求就行瞭。如果用戶裡面有懂點程序編碼的，輕而易舉就能破掉。我再去改

組長：其實，我們隻能防君子，哪個系統都有漏洞，沒有絕對的權限控制和安全，但咱們盡量的給做好。

我的第二步嘗試：

在第二步嘗試前，我想瞭一會兒。我發現這個事件有以下幾個突破口：一、像訂單編號這個敏感的數據，能不能做到不被推測出來？二、用戶是根據訪問路徑，然後加上一個ID號去請求，如果用戶拿不到訪問路徑呢？三、要點就是用戶隻能操作自己的數據，我可以在敏感操作的時候，同時校驗當前用戶。四、既然都是@PathVariable這種方式帶來的一些問題，那我可以把相應的方法，換掉這種傳值方式。五、用戶看到的是一個請求方法路徑，我可不可以在路徑中加入隨機密碼鹽，進一步的控制關鍵操作的訪問。

好吧，為瞭方便迅速，我直接把這種傳值方式給改瞭。當然也沒有改完，時間關系，像一些本來就屬於公開數據的內容，還是沒改。

我的第三步嘗試：

在第二步的時候，就已經改完代碼瞭。然後，我覺得我是一個很較真的人。忙裡偷閑，我把我在第二步嘗試中想到瞭幾個點，都寫代碼測瞭測。最先測出來的是第三種（同時檢驗當前用戶，也就簡單類似於where orderID=? and userID=? ） 其次，還測瞭測那個密碼鹽值，也確實能夠控制住，但是，想瞭想系統的性質和資源的最終走向，沒改。然後，去禁止用戶打開開發者工具或者查看源代碼，然而，這根本不是我能控制住的。我也最多就是能控制住快捷鍵打開，但人傢還有鼠標啊？？？？？？瀏覽器提供的功能，不是我想幹掉就幹掉滴滴滴滴。

我的第一個方案，就是改造訂單生成的方式，然後我覺得吧，這個好像不怎麼靠譜。但毫無疑問比當前的生成方式要靠譜得太多，但這要改動下來，呃，原諒我很慫。

二、個人總結

我最大的問題，不是我後來想不出更為優雅的方案去解決，而是，我從根本上，對這是個問題的問題毫無知覺。我甚至都不覺得那樣有什麼問題，這才是我最該考慮的點。

其實，我用@PathVariable或者什麼別的方式去傳值，這都無可厚非。但我也應該更進一步的考慮到它的應用場景和系統功能鎖涉及到的數據，以及可能帶來的後果。就比如說我這個@PathVariable的問題，在別的查詢一些區域信息（公共展示數據）的時候，我也這麼用瞭，組長也看見瞭，但為什麼他著重說瞭訂單這一塊，還要求這一塊必須改。反正，我就是欠思考。。。。。。

很多很多的東西，都是建立在日常生活體驗上的。我以前就很崇拜架構師，現在也很崇拜。但是，我突然明白，架構師也不是光有空架子的。就比如說我自己吧，我還算是亂七八糟的想法挺多的那種（雖然並不是每個都靠譜）但是，做事情不能光憑想象，要實際操作的。

感覺最近做得比較好一點的就是：

1，因為有一個地方查詢的數據有很多，那天我跟組長提出，我要換一種查詢方法，提升查詢效率。然後組長就問我究竟想怎麼換？我就直接同時運行瞭兩套代碼幹同樣的事兒給他看，結果，就很so easy的換成瞭我想換的那種方式，我想說的話，全都在代碼裡。後來弄完瞭，閑下來，我解釋瞭一下不同點，關鍵點。

2，因為強調代碼規范和效率嘛。我就在自己私下寫代碼的時候，旁邊就放著一本代碼整潔之道，還有阿裡代碼規范手冊，然後還有我閑下來的時候，去官網找的一些常用數據結構、數據類型的應用對比。我是一邊寫，一邊看。有不知道怎麼寫的，就幹脆先看一眼，照著書寫。剛開始挺痛苦的，因為寫一句就錯一句，也不能說錯，就是不夠優美。但是，感覺現在慢慢變得好瞭特別特別多。

所謂經驗，就是經常體驗。多寫代碼多思考，一定要多寫代碼，多寫優雅的代碼。

以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。

推薦閱讀：

• 基於SpringMVC @RequestMapping的參數和用法
• URL @PathVariable 變量的匹配原理分析
• SpringMVC中請求參數的獲取方式
• SpringMVC @RequestMapping註解詳解
• SpringMVC 接收前端傳遞的參數四種方式小結