URL矩阵参数与请求参数 [英] URL matrix parameters vs. request parameters

查看:687
本文介绍了URL矩阵参数与请求参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想知道是否在我的网址中使用矩阵或查询参数。我发现该主题的旧版讨论不满意。

I'm wondering whether to use matrix or query parameters in my URLs. I found an older discussion to that topic not satisfying.

示例

  • URL with query params: http://some.where/thing?paramA=1&paramB=6542
  • URL with matrix params: http://some.where/thing;paramA=1;paramB=6542

乍一看,矩阵参数似乎只有优势:

At first sight matrix params seem to have only advantages:


  • 更具可读性

  • 没有编码和解码&在XML文档中是必需的

  • 带有?的URL在很多情况下都没有缓存;带有矩阵参数的URL被缓存

  • 矩阵参数可以出现在路径的任何地方,并且不限于它的结尾

  • 矩阵参数可以有多个值: paramA = val1,val2

  • more readable
  • no encoding and decoding of "&" in XML documents is required
  • URLs with "?" are not cached in many cases; URLs with matrix params are cached
  • matrix parameters can appear everywhere in the path and are not limited to its end
  • matrix parameters can have more than one value: paramA=val1,val2

但也有缺点:


  • 只有少数几个框架,如 JAX-RS 支持矩阵参数

  • 当浏览器通过GET提交表单时,参数变为查询参数。因此,对于同一任务,它最终会出现两种参数。为了不混淆REST服务的用户并限制服务开发人员的工作量,在这个区域使用始终查询参数会更容易。

  • only a few frameworks like JAX-RS support matrix parameters
  • When a browser submits a form via GET, the params become query params. So it ends up in two kinds of parameters for the same task. To not confuse users of the REST services and limit the effort for the developers of the services, it would be easier to use always query params - in this area.

由于服务开发人员可以选择支持矩阵参数的框架,唯一的缺点是浏览器默认创建查询参数。

Since the developer of the service can choose a framework with matrix param support, the only remaining disadvantage would be that browsers create by default query parameters.

还有其他缺点吗?你会做什么?

Are there any other disadvantages? What would you do?

推荐答案

重要的区别是矩阵参数适用于特定路径元素,而查询参数适用于请求作为一个整体。当对多个级别的资源和子资源进行复杂的REST样式查询时,这就起到了作用:

The important difference is that matrix parameters apply to a particular path element while query parameters apply to the request as a whole. This comes into play when making a complex REST-style query to multiple levels of resources and sub-resources:

http://example.com/res/categories;name=foo/objects;name=green/?page=1

这真的归结为命名空间。如果仅使用查询参数,则最终会使用category_name和object_name之类的参数,并且您将失去请求中参数的位置所添加的清晰度。此外,当使用像JAX-RS这样的框架时,所有查询参数都会显示在每个资源处理程序中,从而导致潜在的冲突和混淆。

It really comes down to namespacing. If only query parameters were used, you would end up with parameters like "category_name" and "object_name" and you would lose the clarity added by the locality of the parameters within the request. In addition, when using a framework like JAX-RS, all the query parameters would show up within each resource handler, leading to potential conflicts and confusion.

如果您的查询有只有一个级别,那么差异并不重要,两种类型的参数可以有效地互换,但查询参数通常得到更好的支持和更广泛的认可。一般来说,我建议您坚持使用HTML表单和简单的单级HTTP API之类的查询参数。

If your query has only one "level", then the difference is not really important and the two types of parameters are effectively interchangeable, however query parameters are generally better supported and more widely recognized. In general, I would recommend that you stick with query parameters for things like HTML forms and simple, single-level HTTP APIs.

这篇关于URL矩阵参数与请求参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆