何时使用 @QueryParam 与 @PathParam

本文介绍了何时使用 @QueryParam 与 @PathParam的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

这是一个最佳实践"或惯例问题.

你什么时候使用 @PathParam 和 @QueryParam.

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

PathParam 可以保留用于信息类别，它可以很好地落入信息树的一个分支中.PathParam 可用于深入到实体类层次结构.

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

例如

/Vehicle/Car?registration=123
/House/Colonial?region=newengland

/category?instance

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

vs /category/instance

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

vs ?category+instance

@GET@Path("/员工")患者 getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

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

解决方案

REST 本身可能不是一个标准，但是阅读通用 REST 文档和博客文章应该会给您一些指导来构建 API URL 的好方法.大多数 REST API 在路径中往往只有资源名称和资源 ID.如:

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

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

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

I am not asking the question that is already asked here:What is the difference between @PathParam and @QueryParam

This is a "best practices" or convention question.

When would you use @PathParam vs @QueryParam.

What I can think of that the decision might be using the two to differentiate the information pattern. Let me illustrate below my LTPO - less than perfect observation.

PathParam use could be reserved for information category, which would fall nicely into a branch of an information tree. PathParam could be used to drill down to entity class hierarchy.

Whereas, QueryParam could be reserved for specifying attributes to locate the instance of a class.

For example,

/Vehicle/Car?registration=123
/House/Colonial?region=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 ?category+instance

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

I don't think there is a standard convention of doing it. Is there? However, I would like to hear of how people use PathParam vs QueryParam to differentiate their information like I exemplified above. I would also love to hear the reason behind the practice.

解决方案

REST may not be a standard as such, but reading up on general REST documentation and blog posts should give you some guidelines for a good way to structure API URLs. Most rest APIs tend to only have resource names and resource IDs in the path. Such as:

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

Some REST APIs use query strings for filtering, pagination and sorting, but Since REST isn't a strict standard I'd recommend checking some REST APIs out there such as github and stackoverflow and see what could work well for your use case.

I'd recommend putting any required parameters in the path, and any optional parameters should certainly be query string parameters. Putting optional parameters in the path will end up getting really messy when trying to write URL handlers that match different combinations.

这篇关于何时使用 @QueryParam 与 @PathParam的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！