何时使用@QueryParam vs @PathParam

Question

我不是在问这里已经问过的问题： @PathParam和@QueryParam之间有什么区别

这是“最佳实践”或惯例问题。

当你使用@PathParamVS @QueryParam。

我能想到的是，决定可能是使用二者来区分信息模式。让我在下面说明我的LTPO - 不完美的观察。

PathParam的使用可以保留用于信息类别，这可以很好地落入信息树的分支中。PathParam可用于深入到实体类层次结构。

而QueryParam可以保留用于指定属性以定位类的实例。

例如，

/Vehicle/Car?registration=123

/House/Colonial?region=newengland

/category?instance

@GET

@Path("/employee/{dept}")

Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

VS /category/instance

@GET

@Path("/employee/{dept}/{id}")

Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

VS ?category+instance

@GET

@Path("/employee")

Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

我不认为有这样做的标准惯例。在那儿？但是，我想知道人们如何使用PathParam与QueryParam来区分他们的信息，就像上面举例说明的那样。我也很想听听练习背后的原因。

Answer 1

REST可能不是这样的标准，但阅读一般REST文档和博客文章应该为您提供一些构建API URL的好方法的指南。大多数rest API往往只在路径中包含资源名称和资源ID。如：/departments/{dept}/employees/{id}一些REST API使用查询字符串进行过滤，分页和排序，但由于REST不是严格的标准，我建议检查一些REST API，例如github和stackoverflow，看看哪种方法可以很好地用于您的用例。我建议在路径中放置任何必需的参数，任何可选参数当然应该是查询字符串参数。在尝试编写匹配不同组合的URL处理程序时，将可选参数放在路径中会变得非常混乱。

Answer 2

这就是我的工作。如果存在基于id检索记录的方案，例如，您需要获取id为15的员工的详细信息，那么您可以使用@PathParam获取资源。GET /employee/{id}如果您需要获取所有员工的详细信息，但一次只能获取10个，则可以使用查询参数GET /employee?start=1&size=10这表示启动员工ID 1获得10条记录。总而言之，使用@PathParam进行基于id的检索。用户@QueryParam用于过滤器，或者如果您有任何用户可以传递的固定选项列表。