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

例如,

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

or

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

在哪里

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

资源:订单

queryParam:点= 12345678

PathParam: 12345678

@QueryParam:

当需求是基于特定的条件/标准筛选请求时，使用QueryParam。标准是用?URL中资源的后面。queryParam中可以使用&符号指定多个过滤标准。

例如:

https://app.orderser.com/orders?order=12345678 &客户名=X

@PathParam:

当需要基于guid/id选择特定的顺序时，使用PathParam。PathParam是URL中资源的一部分。

例如:

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

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

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

可以使用查询参数进行过滤，使用路径参数进行分组。下面的链接有关于何时使用pathParams或QueryParams的很好的信息

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

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

可选查询，以问号(?)与前一部分隔开，包含非分层数据的查询字符串。

-根据URL的概念设计，我们可以为分层数据/指令/定位器组件实现一个PathParam，或者当数据不是分层时实现一个QueryParam。这是有意义的，因为路径是自然有序的，而查询包含的变量可能是任意有序的(无序的变量/值对)。

之前的一位评论者写道，

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

另一个写道:

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

另一个,

我建议在路径中放入任何必需的参数，而任何可选参数都应该是查询字符串参数。

— However, one might implement a flexible, non-hierarchical system for identifying specific entities! One might have multiple unique indexes on an SQL table, and allow entities to be identified using any combination of fields that comprise a unique index! Different combinations (perhaps also ordered differently), might be used for links from various related entities (referrers). In this case, we might be dealing with non-hierarchical data, used to identify individual entities — or in other cases, might only specify certain variables/fields — certain components of unique indexes — and retrieve a list/set of records. In such cases, it might be easier, more logical and reasonable to implement the URLs as QueryParams!

Could a long hexadecimal string dilute/diminish the value of keywords in the rest of the path? It might be worth considering the potential SEO implications of placing variables/values in the path, or in the query, and the human-interface implications of whether we want users to be able to traverse/explore the hierarchy of URLs by editing the contents of the address bar. My 404 Not Found page uses SSI variables to automatically redirect broken URLs to their parent! Search robots might also traverse the path hierarchy. On the other hand, personally, when I share URLs on social media, I manually strip out any private unique identifiers — typically by truncating the query from the URL, leaving only the path: in this case, there is some utility in placing unique identifiers in the path rather than in the query. Whether we want to facilitate the use of path components as a crude user-interface, perhaps depends on whether the data/components are human-readable or not. The question of human-readability relates somewhat to the question of hierarchy: often, data that may be expressed as human-readable keywords are also hierarchical; while hierarchical data may often be expressed as human-readable keywords. (Search engines themselves might be defined as augmenting the use of URLs as a user-interface.) Hierarchies of keywords or directives might not be strictly ordered, but they are usually close enough that we can cover alternative cases in the path, and label one option as the "canonical" case.

对于每个请求的URL，我们可能会回答几种基本的问题:

我们要求/提供什么样的记录/东西? 我们对哪一个感兴趣? 我们希望如何呈现信息/记录?

Q1几乎肯定最好由路径或PathParams覆盖。 Q3(可能通过一组任意顺序的可选参数和默认值进行控制);几乎可以肯定QueryParams是最好的。 这要看情况……

这是个很有趣的问题。

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

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

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

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

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

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

/城市/经度,纬度

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

/ IconGenerator /红色,蓝色,绿色

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

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

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

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

REST本身可能不是一个标准，但是阅读一般的REST文档和博客文章应该会给你一些指导，让你更好地构造API url。大多数其他api倾向于在路径中只有资源名称和资源id。如:

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

一些REST api使用查询字符串进行过滤，分页和排序，但由于REST不是一个严格的标准，我建议检查一些REST api，如github和stackoverflow，看看什么可以很好地为您的用例工作。

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