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

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

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

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

根据我的理解:

使用@PathParam -当它是一个强制性的项目，如Id 获得/气球/ {id} 使用@QueryParam -当你有确切的资源，但需要过滤一些可选的特征，如颜色，大小等。 得到/气球/ 123 ?颜色= red&size =

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

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

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

-根据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是最好的。 这要看情况……

我喜欢以下几点:

@PathParam

当需要参数时，例如ID, productNo .

GET /user/details/{ID}
GET /products/{company}/{productNo}

@QueryParam

当您需要传递可选参数，如过滤器，在线状态和他们可以为空

GET /user/list?country=USA&status=online
GET /products/list?sort=ASC 

同时使用时

GET /products/{company}/list?sort=ASC 

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

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

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