原文地址: When to use @QueryParam vs @PathParam
题主的理解是：对于一些有上下级关系的资源（比如部门和员工有父子关系）, 可以把它们的结构想象成一棵树。PathParam注解可以用来当做某一类分支资源的占位符。适合用在需要下钻的场景。
而QueryParam注解用在查找满足某些属性的那些资源。举例:
/Vehicle/Car?registration=123/House/Colonial?region=newengland
几种组合方式(?代表使用QueryParam)
/category?instance (两者都有)
@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;
vs /category/instance (只有PathParam)
@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;
vs ?category+instance (只有QueryParam)
@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;
也许对这两者的使用并没有一个明确的规范，但是我想听听大家在项目中是如何使用的？为什么这样用？
网友 theon
REST可能不是这样的标准，但是阅读REST文档和博客文章应该会给你提供一些构建API URL的好方法。大多数REST API在路径中只提供资源名和资源ID。比如
/depatments/{dept}/employees/{id}
REST的API在过滤、分页和排序的时候会用到QueryParam，但由于REST不是一个严格的标准，我建议你学习一些比较优秀的API设计，比如github 和 stackoverflow。看看哪种情况更适合你。
我建议在路径中放置那些必需的参数（PathParam），而可选参数应该作为查询字符串(QueryParam)。在URL中滥用QueryParam将会使得URL handlers在匹配不同参数组合的时候变得非常混乱。
网友 10GritSandpaper
我认为，如果参数标识一个特定的实体，您应该使用PATH变量。例如，为了获得我博客上的所有帖子，我这样请求
GET: myserver.com/myblog/posts
为了得到id = 123的帖子, 改为这样
GET: myserver.com/myblog/posts/123
但是为了过滤我的帖子, 比如获取2013年1月1日之后的帖子, 就要这样:
GET: myserver.com/myblog/posts?since=2013-01-01
第一个例子中 "posts" 指向一个特定的实体 (所有帖子的集合). 第二个例子中, "123" 也指向一个特定实体 (一个帖子). 但在最后一个例子中, 参数"since=2013-01-01"是过滤帖子集合的请求，而不是特定实体。分页和排序也是好的例子,比如:
GET: myserver.com/myblog/posts?page=2&order=backward