我不是在问这里已经问过的问题: @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来区分他们的信息,就像我上面举例的那样。我也很想知道这种做法背后的原因。


当前回答

我认为,如果参数标识一个特定的实体,您应该使用路径变量。例如,为了获得我所请求的博客上的所有帖子

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”是一个过滤posts集合的请求,而不是一个特定的实体。分页和排序是另一个很好的例子。

GET: myserver.com/myblog/posts?page=2&order=backward

希望这能有所帮助。:-)

其他回答

我个人使用的方法是“如果对用户来说书签包含这些参数的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.

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

对于资源名称和id,我使用@PathParams。对于可选变量,我使用@QueryParams

这是个很有趣的问题。

你可以同时使用它们,关于这个主题没有任何严格的规则,但是使用URI路径变量有一些优点:

缓存: 大多数互联网上的web缓存服务不缓存GET请求时,他们包含查询参数。 他们这样做是因为有很多RPC系统使用GET请求来更改服务器中的数据(失败!!)Get必须是一个安全的方法)

但是如果使用路径变量,所有这些服务都可以缓存GET请求。

层次结构: 路径变量可以表示层次结构: /城市/街道/的地方

它为用户提供了关于数据结构的更多信息。

但如果你的数据没有任何层次关系,你仍然可以使用Path变量,使用逗号或分号:

/城市/经度,纬度

作为规则,当参数的顺序重要时使用逗号,当顺序不重要时使用分号:

/ IconGenerator /红色,蓝色,绿色

除了这些原因之外,在某些情况下,使用查询字符串变量是非常常见的:

当您需要浏览器自动将HTML表单变量放入URI时 当你处理算法的时候。例如谷歌引擎使用查询字符串:

http:// www.google.com/search ? q =休息

总而言之,没有任何强烈的理由使用这种方法,但只要可以,就使用URI变量。

简而言之,

@Pathparam适用于通过资源和查询字符串传递的值

/用户/1 /user?id=1

@Queryparam只适用于传递查询字符串的值

/user?id=1

正如席恩所指出的,REST不是一个标准。但是,如果您希望实现基于标准的URI约定,则可以考虑oData URI约定。Ver 4已被批准为OASIS标准,并且存在用于各种语言的oData库,包括通过Apache Olingo的Java。不要因为它是微软的产物而放弃它,因为它也获得了其他行业参与者的支持,包括红帽、思杰、IBM、黑莓、Drupal、Netflix Facebook和SAP

这里列出了更多的采用者