我不是在问这里已经问过的问题: @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来区分他们的信息,就像我上面举例的那样。我也很想知道这种做法背后的原因。


当前回答

我给一个例子来理解我们什么时候使用@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中是可选的。

其他回答

根据我的理解:

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

这就是我的工作。

如果存在基于id检索记录的场景,例如您需要获取id为15的员工的详细信息,那么您可以使用@PathParam资源。

GET /employee/{id}

如果需要获得所有员工的详细信息,但每次只需要10个,则可以使用query param

GET /employee?start=1&size=10

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

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

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

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

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

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

路径参数- 路径参数是URL路径中的一个变量,帮助指向一些特定的资源。

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

这里,如果115是一个路径参数,它可以用其他有效的数字来改变,以获取/指向同一应用程序上的其他一些资源。

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

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

其中qp1、qp2和qp3为查询变量,其值分别为val1、val2和val3。在获取/保存数据时,这些可以用作过滤器。查询变量总是在URL中以问号(?)结尾。

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