方法参数相关属性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，因为强调代码规范和效率嘛。我就在自己私下写代码的时候，旁边就放着一本代码整洁之道，还有阿里代码规范手册，然后还有我闲下来的时候，去官网找的一些常用数据结构、数据类型的应用对比。我是一边写，一边看。有不知道怎么写的，就干脆先看一眼，照着书写。刚开始挺痛苦的，因为写一句就错一句，也不能说错，就是不够优美。但是，感觉现在慢慢变得好了特别特别多。
所谓经验，就是经常体验。多写代码多思考，一定要多写代码，多写优雅的代码。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。
原文链接：https://blog.csdn.net/j080624/article/details/56280382
