何时使用@QueryParam与@PathParam

Question

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

这是一个“最佳做法”或惯例问题。

何时使用@PathParam和@QueryParam。

我能想到的是，这个决定可能是利用这两者来区分信息模式。让我在下面举例说明我的LTPO-不够完美的观察。

PathParam的使用可以保留给information category,它很好地属于information Tree的一个分支。PathParam可用于向下钻取实体类层次结构。

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

null

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

vs？类别+实例

@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处理程序时，将可选参数放入路径中最终会变得非常混乱。