何时使用@QueryParam vs @PathParam
我不问这个已经问过的问题： @PathParam和@QueryParam有什么区别？
这是“最佳做法”或公约问题。
什么时候你会使用@PathParam vs @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) ;
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来区分他们的信息，就像我上面的例子。 我也很想听听练习背后的原因。
REST可能并不是一个标准，但是阅读一般的REST文档和博客post应该会给你一些关于构buildAPI URL的好方法的指导。 大多数其余的API往往只有path中的资源名称和资源ID。 如：
/depatments/{dept}/employees/{id}
一些REST API使用查询string进行过滤，分页和sorting，但由于REST不是一个严格的标准，我build议检查一下REST API，比如github和stackoverflow ，看看你的用例能够很好地工作。
我build议在path中放置任何必需的参数，任何可选参数都应该是查询string参数。 将可选参数放在URL中，当尝试编写匹配不同组合的URL处理程序时，最终会变得非常混乱。
这就是我所做的。
如果有一个scheme基于id检索logging，例如，您需要获取id为15的员工的详细信息，那么您可以使用@PathParam获取资源。
GET /employee/{id}
如果有一种情况需要获得所有员工的详细信息，但一次只能获得10个，则可以使用查询参数
GET /employee?start=1&size=10
这就是说，开始员工ID 1得到十条logging。
总结一下，使用@PathParam进行基于id的检索。 User @ QueryParam进行筛选，或者如果您有任何固定的用户可以传递的选项列表。
我认为，如果参数标识一个特定的实体，你应该使用一个pathvariables。 例如，要获得我的博客上的所有post，我请求
GET: myserver.com/myblog/posts
要获得ID = 123的职位，我会要求
GET: myserver.com/myblog/posts/123
但要筛选我的post列表，并获得2013年1月1日以来的所有post，我会请求
GET: myserver.com/myblog/posts?since=2013-01-01
在第一个例子中，“post”标识了一个特定的实体（博客post的整个集合）。 在第二个例子中，“123”也代表一个特定的实体（一个博客文章）。 但在最后一个例子中，参数“since = 2013-01-01”是一个请求来过滤posts集合，而不是一个特定的实体。 分页和sorting将是另一个很好的例子，即
GET: myserver.com/myblog/posts?page=2&order=backward
希望有所帮助。 🙂
您可以使用查询参数进行过滤和path参数进行分组。 下面的链接有更好的信息何时使用pathParams或QueryParams
我个人使用的方法是“如果用户为包含这些参数的URL添加书签，然后使用PathParam”。
例如，如果用户configuration文件的URL包含一些configuration文件ID参数，因为这可以由用户加书签和/或通过电子邮件发送，我将包括该configuration文件ID作为path参数。 另外，另一个想到的是，包含path参数的URL所表示的页面没有改变 – 用户将build立他/她的configuration文件，保存它，然后不太可能从那里改变; 这意味着webcrawlers /search引擎/浏览器/等可以caching这个页面很好地根据path。
如果在URL中传递的参数可能会改变页面布局/内容，那么我会用它作为查询参数。 例如，如果configuration文件URL支持指定是否显示用户电子邮件的参数，我会认为这是一个查询参数。 （我知道，可以说，你可以说， &noemail=1或者其他任何参数都可以用作path参数，并生成两个单独的页面 – 一个是电子邮件，一个没有它 – 但从逻辑上说，这不是情况：它仍然是相同的页面显示或不显示某些属性。
希望这有助于 – 我明白的解释可能有点模糊:)
这是一个非常有趣的问题。
你可以使用它们两个，对这个主题没有任何严格的规则，但是使用URIpathvariables有一些优点：
- caching ：互联网上的大多数Webcaching服务在包含查询参数时都不cachingGET请求。 他们这样做是因为有很多RPC系统使用GET请求来更改服务器中的数据（失败!!获取必须是安全的方法）
但是，如果您使用pathvariables，所有这些服务可以caching您的GET请求。
- 层次结构 ：pathvariables可以表示层次结构：/ City / Street / Place
它为用户提供了关于数据结构的更多信息。
但是，如果您的数据没有任何层次结构关系，则仍然可以使用逗号或分号使用pathvariables：
/市/经度，纬度
通常，在参数sorting时使用逗号，在sorting无关紧要时使用分号。
/ IconGenerator /红色，蓝色，绿色
除了这些原因之外，还有一些情况是使用查询stringvariables很常见：
- 当您需要浏览器自动将HTML表单variables放入URI中时
- 当你正在处理algorithm。 例如，谷歌引擎使用查询string：
http：// http://www.google.com/search?q=rest
总而言之，没有什么强烈的理由使用这个方法，但是只要你可以使用URIvariables。
如前所述，REST不是一个标准。 但是，如果您正在寻求实现基于标准的URI约定，则可以考虑oData URI约定 。 版本4已被批准为OASIS标准，并且存在用于各种语言（包括通过Apache Olingo的 Java）的oData的库 。 不要让这个事实，它是从微软的产卵，因为它得到了其他行业的球员的支持 ，其中包括红帽，思杰，IBM，黑莓，Drupal，Netflix Facebook和SAP的支持
这里列出了更多的使用者
原因其实很简单。 当使用查询参数时，您可以采用“/”等字符，而您的客户端不需要对其进行html编码。 还有其他原因，但这是一个简单的例子。 至于何时使用pathvariables。 我会说，每当你处理ID或如果pathvariables是一个查询的方向。
- @QueryParam可以方便地与默认值注释一起使用，这样如果没有传递查询参数，就可以避免空指针exception。
当你想从一个GET请求中parsing查询参数时，你可以简单地为处理GET请求的方法定义相应的参数，并用@QueryParam注解对它们进行注释
-
@PathParam提取URI值并匹配到@Path。 因此得到input参数。 2.1 @PathParam可以不止一个，并设置为方法参数
@Path（ “/休息”）
公共课Abc {
@得到
@Path（ “/ MSG / {P0} / {P 1}”）
@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请求的数据。 HTTP表单可以通过GET和POST等不同的方法提交。
@QueryParam：接受GET请求并从查询string读取数据。
@FormParam：接受POST请求，并从HTML表单或媒体的任何请求中获取数据
我将讨论一下，我们何时使用@Queryparam和@pathparam
比如我拿一个资源就是carResource资源类
如果你想让你的资源方法的inputpipe理，那么使用参数types作为@pathaparam ，如果你的资源方法的input应该是可选的，那么保持该参数types为@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这样的资源将给出基础的汽车模型和颜色
req uri://address:2020/carWeb/car/search/swift
如果你给req这样的resoce方法将只显示快速模型的汽车
req://address:2020/carWeb/car/search?carcolor=red
如果你这样给我们，我们将得到ResourceNotFoundexception，因为在汽车资源类中，我将carmodel声明为@pathPram ，你必须并且应该给carmodel做reQ uri，否则它不会传递req来资源，但是如果你不通过颜色也会通过req来资源为什么因为颜色是@quetyParam在req中是可选的。
统一资源定位器
包含数据的path ， 通常以分层forms组织 ，显示为由斜杠分隔的一系列段。
一个可选查询 ，与前一部分用问号（？）分开，包含一个非层次数据的查询string。
– 根据URL的概念devise，我们可以实现分层数据/指令/定位器组件的PathParam，或者当数据不是分层时实现QueryParam。 这是有道理的，因为path是自然sorting的，而查询包含可以任意sorting的variables（无序variables/值对）。
以前的评论者写道，
我认为，如果参数标识一个特定的实体，你应该使用一个pathvariables。
另一位写道，
使用@PathParam进行基于id的检索。 User @ QueryParam进行筛选，或者如果您有任何固定的用户可以传递的选项列表。
另一个，
我build议在path中放置任何必需的参数，任何可选参数都应该是查询string参数。
但是，我们可以实现一个灵活的非分级系统来识别特定的实体！ 一个人可能在一个SQL表上有多个唯一索引，并且允许使用包含唯一索引的字段的任何组合来识别实体！ 不同的组合（可能还有不同的排列方式）可能用于来自各种相关实体（推荐人）的链接。 在这种情况下，我们可能会处理非分层数据，用于标识单个实体 – 或者在其他情况下，可能只指定某些variables/字段 – 特定索引的某些组件 – 并检索列表/一组logging。 在这种情况下，将URL作为QueryParams实现可能更简单，更合理和合理！
一个很长的hexstring是否会稀释/减lesspath其余部分中关键字的值？ 可能值得考虑将variables/值放在path或查询中的潜在SEO含义 ，以及我们是否希望用户能够通过编辑URL的内容来遍历/浏览URL层次结构的人机界面含义地址栏。 我的404 Not Found页面使用SSIvariables自动将破损的URLredirect到他们的父项！ search机器人也可能遍历path层次结构。 另一方面，当我在社交媒体上共享URL时，我会手动去除任何私有的唯一标识符 – 通常是通过从URL中截断查询，只留下path：在这种情况下，有一些实用工具可以放置唯一的标识符在path中而不是在查询中。 无论我们是否希望将path组件作为粗略的用户界面来使用，可能取决于数据/组件是否可读。 人类可读性问题在一定程度上与层级问题有关：通常，可以expression为人类可读关键字的数据也是分级的; 而分层数据往往可以表示为人类可读的关键字。 （search引擎本身可能被定义为增加使用URL作为用户界面。）关键字或指令的层次结构可能不是严格sorting的，但它们通常足够接近，以便我们可以覆盖path中的其他案例，并标注一个选项作为“规范”的情况 。
我们可能会根据每个请求的URL回答几个基本问题：
- 我们要求/服务是什么样的logging？
- 我们感兴趣的是哪一个？
- 我们如何呈现信息/logging？
Q1几乎肯定是最好的path或PathParams覆盖。 Q3（可能通过一组任意排列的可选参数和默认值进行控制）; QueryParams几乎肯定是最好的。 Q2：这取决于…
