何时使用@QueryParam vs @PathParam [英] When to use @QueryParam vs @PathParam
问题描述
我不是问这里已经提出的问题：
@PathParam和@QueryParam之间有什么区别
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.
您何时使用 @PathParam vs @QueryParam 。
我能想到的是，决定可能会使用这两者来区分信息模式。让我在下面说明我的LTPO - 不是完美的观察。
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的使用可以保留给信息类别，它可以很好地落入信息树的一个分支。 PathParam可用于向下钻取到实体类层次结构。
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.
然而，可以保留QueryParam来指定属性以定位类的实例。
Whereas, QueryParam could be reserved for specifying attributes to locate the instance of a class.
例如，
-
/ Vehicle / Car？registration = 123 -
/ House / Colonial？region = newengland
/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) ;
我认为没有这样做的标准惯例。在那儿？但是，我想知道人们如何使用PathParam和QueryParam来区分他们的信息，就像上面举例说明的那样。我也很想听听练习背后的原因。
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可能不是这样的标准，但是阅读一般的REST文档和博客文章应该为您提供一些构建API URL的好方法的指南。大多数rest API往往只在路径中包含资源名称和资源ID。例如：
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}
一些REST API使用查询字符串进行过滤，分页和排序，但由于REST不是严格的标准，我建议在那里检查一些REST API例如 github 和 stackoverflow ，看看哪些方法可以很好地适用于您的用例。
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.
我建议在路径中放置任何必需的参数，任何可选参数当然应该是查询字符串参数。在尝试编写匹配不同组合的URL处理程序时，在URL中放置可选参数最终会变得非常混乱。
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 URL will end up getting really messy when trying to write URL handlers that match different combinations.
这篇关于何时使用@QueryParam vs @PathParam的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
