何时使用@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处理程序时,在URL中放置可选参数最终会变得非常混乱.

Answer 2

这就是我的工作.

如果存在基于id检索记录的方案,例如,您需要获取id为15的员工的详细信息,那么您可以使用@PathParam获取资源.

GET /employee/{id}

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

GET /employee?start=1&size=10

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

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

Answer 3

我认为如果参数标识特定实体,您应该使用路径变量.例如,要获取我要求的博客上的所有帖子

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

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

希望有所帮助.:-)

Answer 4

在谈论 QueryParam 和 PathParam 之前。让我们首先了解 URL 及其组成部分。URL由端点+资源+queryParam/PathParam组成。

例如，

URL: https://app.orderservice.com/order?order=12345678

或者

URL: https://app.orderservice.com/orders/12345678

在哪里

端点： https: //app.orderservice.com

资源：订单

查询参数：订单=12345678

路径参数：12345678

@QueryParam:

当要求根据某些条件过滤请求时使用 QueryParam。该标准用 ? 指定。URL 中的资源之后。可以在queryParam中使用&符号指定多个过滤条件。

例如：

https://app.orderservice.com/orders?order=12345678 & customername=X

@PathParam:

当要求根据 guid/id 选择特定订单时使用 PathParam。PathParam是URL中资源的部分。

例如：

https://app.orderservice.com/orders/12345678

Answer 5

我个人使用"如果用户为包含这些参数的URL添加书签然后使用PathParam"的方法.

例如,如果用户配置文件的URL包括一些配置文件ID参数,因为这可以由用户和被书签/或围绕电子邮件,我会包括个人资料的ID作为路径参数.此外,另一个considerent这是该网页由包括路径PARAM不改变URL表示 - 用户将建立他/她的个人资料,保存它,然后不会带来太大变化从那里; 这意味着webcrawlers/search engines/browsers/etc可以根据路径很好地缓存这个页面.

如果URL中传递的参数可能会更改页面布局/内容,那么我将其用作查询参数.例如,如果配置文件URL支持指定是否显示用户电子邮件的参数,我会认为这是一个查询参数.(我知道,可以说,你可以说它&noemail=1或其他参数可以用作路径参数并生成2个单独的页面 - 一个带有电子邮件,一个没有它 - 但从逻辑上讲并非如此:它仍然是显示或不显示某些属性的同一页面.

希望这有帮助 - 我感谢解释可能有点模糊:)

Answer 6

您可以使用查询参数进行过滤,并使用路径参数进行分组.以下链接有关于此的详细信息何时使用pathParams或QueryParams

Answer 7

这是一个非常有趣的问题。

您可以同时使用它们，对此主题没有严格的规定，但是使用URI路径变量具有一些优点：

• 缓存：Internet上的大多数Web缓存服务在包含查询参数时都不会缓存GET请求。他们这样做是因为有很多RPC系统使用GET请求来更改服务器中的数据（失败！获取必须是一种安全的方法）

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

• 层次结构：路径变量可以表示层次结构：/ City / Street / Place

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

但是，如果您的数据没有任何层次关系，您仍然可以使用逗号或分号来使用Path变量：

/城市/经度，纬度

通常，在参数顺序很重要时，请使用逗号；在顺序无关紧要时，请使用分号：

/ IconGenerator /红色；蓝色；绿色

除了这些原因外，在某些情况下，使用查询字符串变量也很常见：

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

http：// www.google.com/search?q=rest

综上所述，没有充分的理由使用其中一种方法，但是只要有可能，就使用URI变量。

Answer 8

来自维基百科：统一资源定位器

\n\n

包含数据的路径，通常以分层形式组织，显示为由斜杠分隔的一系列段。

\n\n

可选查询，与前面的部分用问号（?）分隔，包含非分层数据的查询字符串。

\n\n

\xe2\x80\x94 根据 URL 的概念设计，我们可以为分层数据/指令/定位器组件实现 PathParam，或者在数据不分层时实现 QueryParam。这是有道理的，因为路径是自然排序的，而查询包含可以任意排序的变量（无序变量/值对）。

\n\n

之前的评论者写道，

\n\n

\n

我认为如果参数标识特定实体，则应该使用路径变量。

\n

\n\n

另一位写道，

\n\n

\n

使用@PathParam根据id进行检索。用户@QueryParam作为过滤器，或者如果您有用户可以传递的任何固定选项列表。

\n

\n\n

其他，

\n\n

\n

我建议将任何必需的参数放入路径中，并且任何可选参数当然应该是查询字符串参数。

\n

\n\n

\xe2\x80\x94 然而，人们可能会实现一种灵活的、非分层的系统来识别特定的实体！SQL 表上可能有多个唯一索引，并允许使用构成唯一索引的字段的任意组合来标识实体！不同的组合（可能也以不同的顺序排列）可以用于来自各种相关实体（引用者）的链接。在这种情况下，我们可能正在处理非分层数据，用于识别各个实体 \xe2\x80\x94 或者在其他情况下，可能只指定某些变量/字段 \xe2\x80\x94 唯一索引的某些组件 \xe2 \x80\x94 并检索记录列表/集。在这种情况下，将 URL 实现为 QueryParams 可能会更容易、更合乎逻辑、更合理！

\n\n

长十六进制字符串是否会稀释/减少路径其余部分中关键字的值？可能值得考虑在路径或查询中放置变量/值的潜在 SEO 影响，以及我们是否希望用户能够通过编辑 URL 的内容来遍历/探索 URL 层次结构的人机界面影响地址栏。我的 404 Not Found 页面使用 SSI 变量自动将损坏的 URL 重定向到其父级！搜索机器人也可能遍历路径层次结构。\n另一方面，就我个人而言，当我在社交媒体上共享 URL 时，我通常通过截断 URL 中的查询来手动删除任何私有唯一标识符 \xe2\x80\x94，只留下路径：在这种情况下，将唯一标识符放置在路径中而不是查询中具有一些实用性。我们是否想要促进将路径组件用作原始用户界面，可能取决于数据/组件是否是人类可读的。人类可读性的问题在某种程度上与层次结构问题相关：通常，可以表示为人类可读关键字的数据也是层次结构的；而分层数据通常可以表示为人类可读的关键字。（搜索引擎本身可能被定义为增强 URL 作为用户界面的使用。）关键字或指令的层次结构可能没有严格排序，但它们通常足够接近，我们可以覆盖路径中的替代情况，并标记一个选项作为“规范”情况。

\n\n

从根本上来说，我们可以通过每个请求的 URL 来回答以下几种问题：

\n\n

\n
1. 我们请求/提供什么样的记录/东西？
\n
2. 我们对哪些感兴趣？
\n
3. 我们要如何呈现信息/记录？
\n

\n\n

几乎可以肯定，Q1 最好由路径或 PathParams 覆盖。\nQ3（可能通过一组任意排序的可选参数和默认值进行控制）；几乎肯定是 QueryParams 最好地覆盖。\nQ2：这取决于\xe2\x80\xa6

\n