这是个很有趣的问题。

你可以同时使用它们，关于这个主题没有任何严格的规则，但是使用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

原因其实很简单。当使用查询参数时，你可以输入字符，如“/”，你的客户端不需要对它们进行html编码。还有其他原因，但这只是一个简单的例子。至于何时使用路径变量。我想说的是，当你处理id或者路径变量是一个查询的方向时。

我给一个例子来理解我们什么时候使用@Queryparam和@pathparam

例如，我正在使用一个资源是carResource类

如果你想让你的资源方法的输入是强制性的，那么使用参数类型为@pathaparam，如果你的资源方法的输入应该是可选的，那么保持参数类型为@QueryParam

@Path("/car")
class CarResource
{
    @Get
    @produces("text/plain")
    @Path("/search/{carmodel}")
    public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
        //logic for getting cars based on carmodel and color
            -----
        return cars
    }
}

为这个资源传递请求

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

如果你给出这样的要求，资源将给出基于汽车的型号和颜色

 req uri://address:2020/carWeb/car/search/swift

如果你给出这样的要求，资源方法将只显示基于快速模型的汽车

req://address:2020/carWeb/car/search?carcolor=red

如果你这样给出，我们会得到ResourceNotFound异常因为在car资源类中，我声明了carmodel为@pathPram也就是说，你必须并且应该将carmodel作为reQ uri，否则它不会将reQ传递给resource但如果你不传递颜色它也会将reQ传递给resource为什么呢因为颜色是@quetyParam，这在reQ中是可选的。

我个人使用的方法是“如果对用户来说书签包含这些参数的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，或者当数据不是分层时实现一个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是最好的。 这要看情况……