何时使用@QueryParam与@PathParam

2022-08-31 04:58:43

我不是在问这里已经提出的问题:@PathParam和@QueryParam

这是一个“最佳实践”或约定问题。

何时会使用 vs .@PathParam@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) ;

/category/instance

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

?category+instance

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

我不认为有一个标准的惯例来做这件事。有吗?但是,我想听听人们如何使用PathParam与QueryParam来区分他们的信息,就像我上面举例的那样。我也想听听这种做法背后的原因。


答案 1

REST本身可能不是一个标准,但阅读一般的REST文档和博客文章应该会给你一些指导,帮助你找到一种构建API URL的好方法。大多数 rest API 往往在路径中只有资源名称和资源 ID。如:

/departments/{dept}/employees/{id}

一些REST API使用查询字符串进行过滤,分页和排序,但由于REST不是一个严格的标准,我建议检查一些REST API,如githubstackoverflow,看看什么可以很好地适用于你的用例。

我建议在路径中放置任何必需的参数,任何可选参数当然都应该是查询字符串参数。在路径中放置可选参数最终会在尝试编写匹配不同组合的 URL 处理程序时变得非常混乱。


答案 2

这就是我的工作。

如果存在基于 id 检索记录的方案,例如,您需要获取 id 为 15 的员工的详细信息,则可以拥有具有 @PathParam。

GET /employee/{id}

如果存在需要获取所有员工的详细信息,但一次只能获取 10 个员工的详细信息,则可以使用查询参数

GET /employee?start=1&size=10

这表示启动员工 ID 1 将获得 10 条记录。

总而言之,请使用@PathParam进行检索,该列表基于 id.用户@QueryParam进行筛选,或者如果您有任何用户可以传递的选项的固定列表。