@QueryParam和@PathParam比较以及@PathParam和斜杠/的渊源
建议直接跳到结尾。
为了把前端的name值传到后台，使用了@PathParam。后想到若name带有/，会不会出错，一试果然有问题，没法传到后台。
但我不想限制前端输入，故将@PathParam改为@QueryParam，使其以键值对的形式传到后台，真棒，成功了。
那么，@PathParam这么讨厌，居然不能输入/，为什么还要让它存在？
存在必有其道理。所以就上网搜了一下。看到了下面这篇文章：
http://docs.jboss.org/resteasy/2.0.0.GA/userguide/html/_PathParam.html
原来@PathParam还有更复杂的应用场景。
@GET
@Path("/{fileName}.{fileSuffix}")
public ResultBean changeFileName(@PathParam("fileName") String fn, @PathParam("fileSuffix") String fs) {
//...
}
这样， Request请求 GET /woshihenyouxiude.pdf 后台方法得到fn为woshihenyouxiude，fs为pdf
360doc上的这篇文章还举了正则表达式的栗子呢：
@Path("/aaa{param:b+}/{many:.*}/stuff")
public getIt(@PathParam("param")String bs, @PathParam("many")String many) {...}
这样，Request请求
GET /aaabb/some/stuff 后台获得bs为bb，many为some
GET /aaab/a/lot/of/stuff 后台获得bs为b， many为a/lot/of
Oh, My GOD!
many居然可以为a/lot/of，我的天哪！
本来以为@PathParam low low 的。没想到还有这种操作（感觉自己道行太浅，为自己默哀...）。
于是我小试了一下......
前端是这样的：
XXXController.getIt({
param: "aaabb",
many: "a/lot/of"
});
查看浏览器Network，URL是这样的：.../aaaaaabb/a%2flot%2fof/stuff?...
我以为的是前端传入aaabb，URL中应该也是aaabb，然后后台获取到的应该是bb；
我还以为a/lot/of传过去，获取到的也应该是a/lot/of，但根本就没有跳到后台，就报错了。
我把url直接输入在地址栏中，http://.../aaabb/a/lot/of/stuff?...
后台获取到的就是正确的。
然后我看了生成的rest-js文件，又去看了JSAPIWriter源码，发现它会用自己的方式去encode一遍。
唉。。暂时不知道有什么方法能让它不要encode。因为看JSAPIWriter源码，它是无论如何都会去encode的。
我就是结尾。
| @PathParam | @QueryParam |
| 参数映射在URI中，不出现键值对，如/user/71/winneshen | 参数以键值对的形式出现，如/user?id=71&name=winneshen |
| 后台可正则解析得到参数传入方法 | 前端传什么，后台就接收什么 |
后台：
@Controller
@Path("/xxx")
public class XXXController {
@GET
@Path("/aaa{id}/bbb{name}/user")
public ResultBean getUserById (@PathParam("id") Long id, @PathParam("name") String name)
}
前端直接调用后台接口，如XXXController.getUserById({参数和回调})
若前端传了id:71,name:"winneshen"，查看浏览器Nerwork，Request URL会是/aaa71/bbbwinneshen/user
若前端传了id:71,name:"winne/shen"，查看浏览器Nerwork，Request URL会是/aaa71/bbbwinne%2fshen/user，会报400错误，因为resteasy会通过自己的方式自动编码。
若直接在浏览器地址栏输入http://.../xxx/aaa71/bbbwinne/shen/user，则正常，后台获得id为71，name为winne/shen
可通过查看rest-js和JSAPIWriter源码看个究竟。
若上述内容有不对的地方，欢迎批评指正。