什么时候使用@QueryParam和@PathParam

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

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

什么时候使用@PathParam vs @QueryParam。

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

PathParam的使用可以保留在信息类别中，这将很好地归入信息树的一个分支。PathParam可以用于下钻到实体类层次结构。

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

例如,

/ Vehicle /车?车主= 123 / House /克?该区域= 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 ?类别+实例

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

我不认为这样做有一个标准的惯例。是吗?然而，我想知道人们如何使用PathParam和QueryParam来区分他们的信息，就像我上面举例的那样。我也很想知道这种做法背后的原因。

当前回答

@QueryParam可以方便地与默认值注释一起使用，这样如果没有传递查询参数，就可以避免空指针异常。

当您希望解析来自GET请求的查询参数时，您可以简单地为处理GET请求的方法定义相应的参数，并使用@QueryParam注释对它们进行注释

@PathParam提取URI值并与@Path匹配。从而得到输入参数。 @PathParam可以有多个，并且设置为方法参数 @ path(" /休息”) 公共类Abc { @ get @ path(" /味精/ {p0} / {p1}”) 与@ (" text / plain”) public String add(@PathParam("p0") Integer param1， @PathParam("p1") Integer param2) ｛返回String.valueOf (param1 + param2); ｝｝

在上面的例子中， http://localhost: 8080 / Restr /休息/味精/ {p0} / {p1}, P0匹配param1 p1匹配param2。对于URI来说 http://localhost: 8080 / Restr /休息/味精/ 4/6, 结果是10。

在REST服务中，JAX-RS提供了@QueryParam和@FormParam来接受来自HTTP请求的数据。HTTP表单可以通过不同的方法提交，比如GET和POST。

@QueryParam:接受GET请求并从查询字符串中读取数据。

@FormParam:接受POST请求并从HTML表单或媒体的任何请求中获取数据

2016-01-21 12:03:12

其他回答

我个人使用的方法是“如果对用户来说书签包含这些参数的url是有意义的，那么使用PathParam”。

For instance, if the URL for a user profile includes some profile id parameter, since this can be bookmarked by the user and/or emailed around, I would include that profile id as a path parameter. Also, another considerent to this is that the page denoted by the URL which includes the path param doesn't change -- the user will set up his/her profile, save it, and then unlikely to change that much from there on; this means webcrawlers/search engines/browsers/etc can cache this page nicely based on the path.

If a parameter passed in the URL is likely to change the page layout/content then I'd use that as a queryparam. For instance, if the profile URL supports a parameter which specifies whether to show the user email or not, I would consider that to be a query param. (I know, arguably, you could say that the &noemail=1 or whatever parameter it is can be used as a path param and generates 2 separate pages -- one with the email on it, one without it -- but logically that's not the case: it is still the same page with or without certain attributes shown.

希望这能有所帮助——我很感激这个解释可能有点模糊:)

2012-07-19 00:35:19