Ble*_*eek 257 java rest jax-rs
我不是在问这里已经问过的问题: @PathParam和@QueryParam之间有什么区别
这是"最佳实践"或惯例问题.
当你使用@PathParamVS @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来区分他们的信息,就像上面举例说明的那样.我也很想听听练习背后的原因.
the*_*eon 238
REST可能不是这样的标准,但阅读一般REST文档和博客文章应该为您提供一些构建API URL的好方法的指南.大多数rest API往往只在路径中包含资源名称和资源ID.如:
/departments/{dept}/employees/{id}
一些REST API使用查询字符串进行过滤,分页和排序,但由于REST不是严格的标准,我建议检查一些REST API,例如github和stackoverflow,看看哪些可以很好地适用于您的用例.
我建议在路径中放置任何必需的参数,任何可选参数当然应该是查询字符串参数.在尝试编写匹配不同组合的URL处理程序时,在URL中放置可选参数最终会变得非常混乱.
Aru*_*ran 83
这就是我的工作.
如果存在基于id检索记录的方案,例如,您需要获取id为15的员工的详细信息,那么您可以使用@PathParam获取资源.
GET /employee/{id}
如果您需要获取所有员工的详细信息,但一次只能获取10个,则可以使用查询参数
GET /employee?start=1&size=10
这表示启动员工ID 1获得10条记录.
总而言之,使用@PathParam进行基于id的检索.用户@QueryParam用于过滤器,或者如果您有任何用户可以传递的固定选项列表.
10G*_*per 42
我认为如果参数标识特定实体,您应该使用路径变量.例如,要获取我要求的博客上的所有帖子
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"标识特定实体(整个博客帖子集合).在第二个示例中,"123"也表示特定实体(单个博客帖子).但在最后一个示例中,参数"since = 2013-01-01"是过滤帖子集合而不是特定实体的请求.分页和排序将是另一个很好的例子,即
GET: myserver.com/myblog/posts?page=2&order=backward
希望有所帮助.:-)
在谈论 QueryParam 和 PathParam 之前。让我们首先了解 URL 及其组成部分。URL由端点+资源+queryParam/PathParam组成。
例如，
URL: https://app.orderservice.com/order?order=12345678
或者
URL: https://app.orderservice.com/orders/12345678
在哪里
端点： https: //app.orderservice.com
资源：订单
查询参数：订单=12345678
路径参数：12345678
@QueryParam:
当要求根据某些条件过滤请求时使用 QueryParam。该标准用 ? 指定。URL 中的资源之后。可以在queryParam中使用&符号指定多个过滤条件。
例如：
https://app.orderservice.com/orders?order=12345678 & customername=X
@PathParam:
当要求根据 guid/id 选择特定订单时使用 PathParam。PathParam是URL中资源的部分。
例如：
https://app.orderservice.com/orders/12345678
我个人使用"如果用户为包含这些参数的URL添加书签然后使用PathParam"的方法.
例如,如果用户配置文件的URL包括一些配置文件ID参数,因为这可以由用户和被书签/或围绕电子邮件,我会包括个人资料的ID作为路径参数.此外,另一个considerent这是该网页由包括路径PARAM不改变URL表示 - 用户将建立他/她的个人资料,保存它,然后不会带来太大变化从那里; 这意味着webcrawlers/search engines/browsers/etc可以根据路径很好地缓存这个页面.
如果URL中传递的参数可能会更改页面布局/内容,那么我将其用作查询参数.例如,如果配置文件URL支持指定是否显示用户电子邮件的参数,我会认为这是一个查询参数.(我知道,可以说,你可以说它&noemail=1或其他参数可以用作路径参数并生成2个单独的页面 - 一个带有电子邮件,一个没有它 - 但从逻辑上讲并非如此:它仍然是显示或不显示某些属性的同一页面.
希望这有帮助 - 我感谢解释可能有点模糊:)
这是一个非常有趣的问题。
您可以同时使用它们，对此主题没有严格的规定，但是使用URI路径变量具有一些优点：
但是，如果使用路径变量，则所有这些服务都可以缓存GET请求。
它为用户提供了有关数据结构的更多信息。
但是，如果您的数据没有任何层次关系，您仍然可以使用逗号或分号来使用Path变量：
/城市/经度，纬度
通常，在参数顺序很重要时，请使用逗号；在顺序无关紧要时，请使用分号：
/ IconGenerator /红色；蓝色；绿色
除了这些原因外，在某些情况下，使用查询字符串变量也很常见：
http：// www.google.com/search?q=rest
综上所述，没有充分的理由使用其中一种方法，但是只要有可能，就使用URI变量。
包含数据的路径，通常以分层形式组织，显示为由斜杠分隔的一系列段。
\n\n可选查询，与前面的部分用问号（?）分隔，包含非分层数据的查询字符串。
\n\n\xe2\x80\x94 根据 URL 的概念设计，我们可以为分层数据/指令/定位器组件实现 PathParam，或者在数据不分层时实现 QueryParam。这是有道理的，因为路径是自然排序的，而查询包含可以任意排序的变量（无序变量/值对）。
\n\n之前的评论者写道，
\n\n\n\n\n我认为如果参数标识特定实体，则应该使用路径变量。
\n
另一位写道，
\n\n\n\n\n使用@PathParam根据id进行检索。用户@QueryParam作为过滤器，或者如果您有用户可以传递的任何固定选项列表。
\n
其他，
\n\n\n\n\n我建议将任何必需的参数放入路径中，并且任何可选参数当然应该是查询字符串参数。
\n
\xe2\x80\x94 然而，人们可能会实现一种灵活的、非分层的系统来识别特定的实体！SQL 表上可能有多个唯一索引，并允许使用构成唯一索引的字段的任意组合来标识实体！不同的组合（可能也以不同的顺序排列）可以用于来自各种相关实体（引用者）的链接。在这种情况下，我们可能正在处理非分层数据，用于识别各个实体 \xe2\x80\x94 或者在其他情况下，可能只指定某些变量/字段 \xe2\x80\x94 唯一索引的某些组件 \xe2 \x80\x94 并检索记录列表/集。在这种情况下，将 URL 实现为 QueryParams 可能会更容易、更合乎逻辑、更合理！
\n\n长十六进制字符串是否会稀释/减少路径其余部分中关键字的值？可能值得考虑在路径或查询中放置变量/值的潜在 SEO 影响，以及我们是否希望用户能够通过编辑 URL 的内容来遍历/探索 URL 层次结构的人机界面影响地址栏。我的 404 Not Found 页面使用 SSI 变量自动将损坏的 URL 重定向到其父级！搜索机器人也可能遍历路径层次结构。\n另一方面，就我个人而言，当我在社交媒体上共享 URL 时，我通常通过截断 URL 中的查询来手动删除任何私有唯一标识符 \xe2\x80\x94，只留下路径：在这种情况下，将唯一标识符放置在路径中而不是查询中具有一些实用性。我们是否想要促进将路径组件用作原始用户界面，可能取决于数据/组件是否是人类可读的。人类可读性的问题在某种程度上与层次结构问题相关：通常，可以表示为人类可读关键字的数据也是层次结构的；而分层数据通常可以表示为人类可读的关键字。（搜索引擎本身可能被定义为增强 URL 作为用户界面的使用。）关键字或指令的层次结构可能没有严格排序，但它们通常足够接近，我们可以覆盖路径中的替代情况，并标记一个选项作为“规范”情况。
\n\n从根本上来说，我们可以通过每个请求的 URL 来回答以下几种问题：
\n\n几乎可以肯定，Q1 最好由路径或 PathParams 覆盖。\nQ3（可能通过一组任意排序的可选参数和默认值进行控制）；几乎肯定是 QueryParams 最好地覆盖。\nQ2：这取决于\xe2\x80\xa6
\n| 归档时间： |
|
| 查看次数： |
336059 次 |
| 最近记录： |