何时使用@queryparam与@pathparam

swvgeqrz  于 2021-07-03  发布在  Java
关注(0)|答案(8)|浏览(287)

我不是在问已经在这里被问到的问题:@pathparam和@queryparam之间有什么区别
这是一个“最佳实践”或惯例问题。
你什么时候用 @PathParam@QueryParam .
我能想到的是,这个决定可能是用这两者来区分信息模式。让我在下面举例说明我的ltpo——不太完美的观察。
pathparam的用法可以保留给information category,它可以很好地归入信息树的一个分支。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) ;

与 `/category/instance` ```
@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

?category+instance ```
@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

我认为做这件事没有一个标准的惯例。有?然而,我想听听人们是如何使用pathparam和queryparam来区分他们的信息的,就像我上面例举的那样。我也想听听这种做法背后的原因。
mwngjboj

mwngjboj1#

我认为如果参数标识了一个特定的实体,那么应该使用path变量。例如,要获取我博客上的所有帖子,我请求

GET: myserver.com/myblog/posts

为了得到id=123的帖子,我会请求

GET: myserver.com/myblog/posts/123

但要过滤我的帖子列表,获取2013年1月1日以来的所有帖子,我会请求

GET: myserver.com/myblog/posts?since=2013-01-01

在第一个示例中,“posts”标识一个特定的实体(整个blog posts集合)。在第二个示例中,“123”还表示一个特定的实体(一篇博客文章)。但在上一个示例中,参数“since=2013-01-01”是过滤posts集合的请求,而不是特定实体。分页和排序是另一个很好的例子,即。

GET: myserver.com/myblog/posts?page=2&order=backward

希望有帮助。:-)

pbgvytdp

pbgvytdp2#

我个人使用的方法是“如果用户将包含这些参数的url添加为书签是合理的,那么使用pathparam”。
例如,如果用户配置文件的url包含某个配置文件id参数,因为这可以由用户添加书签和/或通过电子邮件发送,所以我会将该配置文件id包含为路径参数。另外,考虑到这一点的另一个因素是,包含路径参数的url所表示的页面不会改变——用户将设置他/她的配置文件,保存它,然后不太可能从此改变那么多;这意味着webcrawler/search engines/browsers/etc可以根据路径很好地缓存这个页面。
如果在url中传递的参数可能会改变页面布局/内容,那么我会将其用作queryparam。例如,如果profileurl支持一个指定是否显示用户电子邮件的参数,我会将其视为一个查询参数(我知道,可以说 &noemail=1 或者,不管它是什么参数,都可以用作path param并生成两个独立的页面——一个包含电子邮件,一个不包含电子邮件——但从逻辑上讲,情况并非如此:无论是否显示某些属性,它仍然是同一个页面。
希望这能有所帮助——我很感激这个解释可能有点模糊:)

8xiog9wr

8xiog9wr3#

可以使用查询参数进行筛选,使用路径参数进行分组。以下链接提供了有关何时使用pathparams或queryparams的详细信息

8oomwypt

8oomwypt4#

这是一个非常有趣的问题。
您可以同时使用它们,关于这个主题没有任何严格的规则,但是使用uri路径变量有一些优点:
缓存:internet上的大多数web缓存服务在包含查询参数时不缓存get请求。他们这样做是因为有很多rpc系统使用get请求来更改服务器中的数据(失败!)!!get必须是一个安全的方法)
但是如果使用路径变量,所有这些服务都可以缓存get请求。
层次结构:路径变量可以表示层次结构:/city/street/place
它为用户提供了有关数据结构的更多信息。
但如果您的数据没有任何层次关系,您仍然可以使用路径变量,使用逗号或分号:
/城市/经度、纬度
通常,参数顺序重要时使用逗号,顺序不重要时使用分号:
/i发电机/红色;蓝色;绿色
除这些原因外,在某些情况下,使用查询字符串变量非常常见:
当您需要浏览器自动将html表单变量放入uri时
当你处理算法的时候。例如,google引擎使用查询字符串:
http://www.google.com/search?q=rest
总而言之,没有任何强有力的理由使用这种方法,但只要可以,就使用uri变量。

ffscu2ro

ffscu2ro5#

rest本身可能不是一个标准,但是阅读一般的rest文档和博客文章可以为您提供一些构造api URL的好方法的指导。大多数restapi的路径中往往只有资源名和资源id。例如:

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

一些restapi使用查询字符串进行过滤、分页和排序,但是由于rest不是一个严格的标准,所以我建议检查一些restapi,比如github和stackoverflow,看看什么可以很好地适用于您的用例。
我建议在路径中放置任何必需的参数,任何可选参数都应该是查询字符串参数。当试图编写匹配不同组合的url处理程序时,将可选参数放在路径中最终会变得非常混乱。

zed5wv10

zed5wv106#

正如席恩所说,休息不是一个标准。但是,如果希望实现基于标准的uri约定,则可以考虑odatauri约定。Ver4已经被批准为oasis标准,并且odata的各种语言都有库,包括通过ApacheOlingo的java。不要因为它是微软的产物而让你失望,因为它也得到了其他行业参与者的支持,包括red hat、citrix、ibm、blackberry、drupal、netflix facebook和sap
这里列出了更多的采用者

n9vozmp4

n9vozmp47#

来自维基百科:统一资源定位器
一种包含数据的路径,通常以层次结构的形式组织,显示为由斜杠分隔的段序列。
一种可选查询,与前面的部分用问号(?)隔开,包含一个非层次数据的查询字符串。
-根据url的概念设计,我们可以为分层数据/指令/定位器组件实现pathparam,或者在数据不是分层的情况下实现queryparam。这是有意义的,因为路径是自然排序的,而查询包含可以任意排序的变量(无序的变量/值对)。
一位前评论员写道,
我认为如果参数标识了一个特定的实体,那么应该使用path变量。
另一个人写道,
根据id使用@pathparam进行检索。user@queryparam用于筛选,或者如果您有任何用户可以传递的固定选项列表。
另一个,
我建议在路径中放置任何必需的参数,任何可选参数都应该是查询字符串参数。
-但是,可以实现一个灵活的、非层次化的系统来识别特定的实体!一个sql表上可能有多个唯一索引,并允许使用构成唯一索引的任何字段组合来标识实体!不同的组合(可能顺序也不同)可能用于来自不同相关实体(引用者)的链接。在这种情况下,我们可能要处理非层次数据,用于标识单个实体,或者在其他情况下,可能只指定某些变量/字段-唯一索引的某些组件-并检索一个列表/一组记录。在这种情况下,将url实现为queryparams可能更简单、更符合逻辑、更合理!
一个长的十六进制字符串会稀释/减少路径其余部分中关键字的值吗?在路径或查询中放置变量/值的潜在seo影响,以及我们是否希望用户能够通过编辑地址栏的内容遍历/浏览URL层次结构的人机界面影响,可能值得考虑。我的404notfound页面使用ssi变量自动将断开的url重定向到它们的父级!搜索机器人也可以遍历路径层次结构。另一方面,就我个人而言,当我在社交媒体上共享url时,我会手动去除任何私有的唯一标识符——通常是通过从url中截取查询,只留下路径:在这种情况下,将唯一标识符放在路径中而不是查询中会有一些用处。我们是否希望方便地将路径组件用作粗糙的用户界面,这可能取决于数据/组件是否是人类可读的。人类可读性问题在某种程度上与层次结构问题有关:通常,可以表示为人类可读关键字的数据也是层次结构的;而层次数据通常可以表示为人类可读的关键字(搜索引擎本身可能被定义为增强URL作为用户界面的使用。)关键字或指令的层次结构可能没有严格的顺序,但它们通常足够接近,我们可以覆盖路径中的其他情况,并将一个选项标记为“规范”情况。
从根本上讲,我们可以用每个请求的url回答几种问题:
我们要什么样的唱片/东西?
我们对哪一个感兴趣?
我们希望如何呈现信息/记录?
q1几乎是ce

gijlo24d

gijlo24d8#

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

GET /employee/{id}

如果有一个场景需要获取所有员工的详细信息,但一次只能获取10个,那么可以使用query param

GET /employee?start=1&size=10

这表示起始雇员id 1得到10条记录。
总而言之,使用@pathparam根据id进行检索。user@queryparam用于筛选,或者如果您有任何用户可以传递的固定选项列表。

相关问题