我不是在问这里已经问过的问题: @PathParam和@QueryParam有什么区别

这是一个“最佳实践”或惯例问题。

什么时候使用@PathParam vs @QueryParam。

我能想到的是,这个决定可能是用这两者来区分信息模式。让我在下面说明我的LTPO -不完美的观察。

PathParam的使用可以保留在信息类别中,这将很好地归入信息树的一个分支。PathParam可以用于下钻到实体类层次结构。

然而,QueryParam可以保留用于指定属性以定位类的实例。

例如,

/ Vehicle /车?车主= 123 / House /克?该区域= 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 ?类别+实例

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

我不认为这样做有一个标准的惯例。是吗?然而,我想知道人们如何使用PathParam和QueryParam来区分他们的信息,就像我上面举例的那样。我也很想知道这种做法背后的原因。


当前回答

正如席恩所指出的,REST不是一个标准。但是,如果您希望实现基于标准的URI约定,则可以考虑oData URI约定。Ver 4已被批准为OASIS标准,并且存在用于各种语言的oData库,包括通过Apache Olingo的Java。不要因为它是微软的产物而放弃它,因为它也获得了其他行业参与者的支持,包括红帽、思杰、IBM、黑莓、Drupal、Netflix Facebook和SAP

这里列出了更多的采用者

其他回答

对于资源名称和id,我使用@PathParams。对于可选变量,我使用@QueryParams

原因其实很简单。当使用查询参数时,你可以输入字符,如“/”,你的客户端不需要对它们进行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中是可选的。

@QueryParam可以方便地与默认值注释一起使用,这样如果没有传递查询参数,就可以避免空指针异常。

当您希望解析来自GET请求的查询参数时,您可以简单地为处理GET请求的方法定义相应的参数,并使用@QueryParam注释对它们进行注释

@PathParam提取URI值并与@Path匹配。从而得到输入参数。 @PathParam可以有多个,并且设置为方法参数 @ path(" /休息”) 公共类Abc { @ get @ path(" /味精/ {p0} / {p1}”) 与@ (" text / plain”) public String add(@PathParam("p0") Integer param1, @PathParam("p1") Integer param2) { 返回String.valueOf (param1 + param2); } }

在上面的例子中, http://localhost: 8080 / Restr /休息/味精/ {p0} / {p1}, P0匹配param1 p1匹配param2。对于URI来说 http://localhost: 8080 / Restr /休息/味精/ 4/6, 结果是10。

在REST服务中,JAX-RS提供了@QueryParam和@FormParam来接受来自HTTP请求的数据。HTTP表单可以通过不同的方法提交,比如GET和POST。

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

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

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

/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