java - 何时使用 @QueryParam 与 @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) ;

对比/category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

对比?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

我不认为有这样做的标准惯例。有没有？但是，我想听听人们如何使用 PathParam 与 QueryParam 来区分他们的信息，就像我上面举例说明的那样。我也很想听听这种做法背后的原因。

score 294 · Accepted Answer

REST 可能不是这样的标准，但阅读一般 REST 文档和博客文章应该为您提供一些指导，以了解构建 API URL 的好方法。大多数 REST API 往往在路径中只有资源名称和资源 ID。如：

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

一些 REST API 使用查询字符串进行过滤、分页和排序，但由于 REST 不是一个严格的标准，我建议您检查一些 REST API，例如github和stackoverflow，看看哪些方法适合您的用例。

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

score 106 · Accepted Answer

这就是我所做的。

如果有根据 id 检索记录的场景，例如需要获取 id 为 15 的员工的详细信息，则可以使用 @PathParam 获取资源。

GET /employee/{id}

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

GET /employee?start=1&size=10

这表示起始员工 id 1 获得 10 条记录。

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

score 49 · Accepted Answer

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

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

在第一个示例中，“帖子”标识了一个特定实体（整个博客帖子集合）。在第二个示例中，“123”还表示特定实体（单个博客文章）。但在最后一个示例中，参数“since=2013-01-01”是过滤帖子集合而不是特定实体的请求。分页和排序将是另一个很好的例子，即

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

希望有帮助。:-)

score 9 · Accepted Answer

我个人使用的方法是“如果用户将包含这些参数的 URL 加入书签有意义，则使用 PathParam”。

例如，如果用户配置文件的 URL 包含一些配置文件 id 参数，因为这可以由用户添加书签和/或通过电子邮件发送，我将包含该配置文件 id 作为路径参数。此外，另一个考虑因素是包含路径参数的 URL 表示的页面不会改变——用户将设置他/她的个人资料，保存它，然后不太可能从那里改变那么多；这意味着网络爬虫/搜索引擎/浏览器/等可以根据路径很好地缓存此页面。

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

希望这会有所帮助——我很欣赏解释可能有点模糊:)

score 8 · Accepted Answer

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

score 6 · Accepted Answer

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

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

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

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

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

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

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

/城市/经度、纬度

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

/IconGenerator/红色;蓝色;绿色

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

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

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

总而言之，没有任何充分的理由使用其中一种方法，但只要可以，请使用 URI 变量。

score 3 · Accepted Answer

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

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

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

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

之前的一位评论者写道，

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

另一位写道，

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

其他，

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

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

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

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

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

几乎可以肯定，Q1 最好由路径或 PathParams 覆盖。Q3（可能通过一组任意排序的可选参数和默认值来控制）；几乎可以肯定 QueryParams 覆盖得最好。Q2：这取决于……</p>

score 2 · Accepted Answer

正如theon 所说，REST 不是标准。但是，如果您希望实现基于标准的 URI 约定，则可以考虑oData URI 约定。版本 4 已被批准为 OASIS 标准，并且存在用于各种语言的 oData 库，包括通过Apache Olingo的 Java 。不要因为它是微软的产物而让你失望，因为它也获得了其他行业参与者的支持，包括 Red Hat、Citrix、IBM、Blackberry、Drupal、Netflix Facebook 和 SAP

此处列出了更多采用者

score 2 · Accepted Answer

您可以同时支持查询参数和路径参数，例如，在资源聚合的情况下——当子资源的集合本身就有意义时。

/departments/{id}/employees
/employees?dept=id

查询参数可以支持分层和非分层子集；路径参数仅是分层的。

资源可以表现出多个层次结构。如果您要查询跨层次边界的广泛子集合，请支持短路径。

/inventory?make=toyota&model=corolla
/inventory?year=2014

使用查询参数来组合正交层次结构。

/inventory/makes/toyota/models/corolla?year=2014
/inventory/years/2014?make=toyota&model=corolla
/inventory?make=toyota&model=corolla&year=2014

在组合的情况下仅使用路径参数——当资源与其父级分离时没有意义，并且所有子级的全局集合本身不是有用的资源。

/words/{id}/definitions
/definitions?word=id   // not useful

score 2 · Accepted Answer

在谈论 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

score 2 · Accepted Answer

PATH PARAMETER - 路径参数是 URL 路径中的一个变量，有助于指向某些特定资源。

Example - https://sitename.com/questions/115

在这里，如果 115 是路径参数，则可以将其更改为其他有效数字以获取/指向同一应用程序上的某些其他资源。

QUERY PARAMETER - 查询参数是 URL 路径中的变量，用于过滤列表中的某些特定资源。

Example - https://sitename.com/questions/115?qp1=val1&qp2=val2&qp3=val3

这里 qp1、qp2 和 qp3 是查询变量，它们的值分别为 val1、val2 和 val3。这些可用于在获取/保存我们的数据时用作过滤器。查询变量总是附加在 URL 中的问号 (?) 之后。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

例如，我正在学习一个资源是carResource类

如果你想让你的资源方法的输入是强制性的，那么使用参数类型 as @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，resouce将给出基于的汽车型号和颜色

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

如果你给 req 这样的 resoce 方法将只显示基于 swift 模型的汽车

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

如果你这样给出，我们将得到 ResourceNotFound 异常，因为在汽车资源类中我声明了汽车模型，因为@pathPram那是你必须并且应该将汽车模型作为 reQ uri 否则它不会将 req 传递给资源，但如果你不传递颜色它还将req传递给资源，因为颜色@quetyParam在req中是可选的。

score 0 · Accepted Answer

@QueryParam可以方便地与 Default Value 注解一起使用，这样可以避免在未传递查询参数时出现空指针异常。

当您想从 GET 请求中解析查询参数时，您可以简单地为将处理 GET 请求的方法定义相应的参数并使用注释对其进行@QueryParam注释

@PathParam提取 URI 值并匹配到@Path. 因此得到输入参数。2.1@PathParam可以多于一个并且设置为方法参数

@Path("/rest")
public class Abc {

    @GET
    @Path("/msg/{p0}/{p1}")
    @Produces("text/plain")
    public String add(@PathParam("p0") Integer param1, @PathParam("p1")  Integer param2 )
    {
        return String.valueOf(param1+param2);
    }
}

在上面的例子中
http://localhost:8080/Restr/rest/msg/{p0}/{p1}，
p0匹配param1和p1匹配param2。所以对于 URI
http://localhost:8080/Restr/rest/msg/4/6，
我们得到了结果10。

在 REST 服务中，JAX-RS 提供@QueryParam和@FormParam两者都用于接受来自 HTTP 请求的数据。可以通过 GET 和 POST 等不同的方法提交 HTTP 表单。

@QueryParam：接受 GET 请求并从查询字符串中读取数据。

@FormParam：接受 POST 请求并从 HTML 表单或媒体的任何请求中获取数据

score 0 · Accepted Answer

简而言之，

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

/user/1
/user?id=1

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

/user?id=1

score 0 · Accepted Answer

0

对于资源名称和 ID，我使用@PathParams. 对于可选变量，我使用@QueryParams

于 2020-11-20T09:59:31.320 回答

score 0 · Accepted Answer

据我了解：

使用@PathParam- 当它是强制性项目时，例如 ID

获取/气球/{id}
使用@QueryParam- 当您拥有确切的资源但需要根据一些可选特征（例如颜色、大小等）对其进行过滤时。

获取 /balloon/123?color=red&size=large

java - 何时使用 @QueryParam 与 @PathParam

17 回答 17

Related

Reference