URLmatrix参数与请求参数

我想知道是否在我的url中使用matrix或查询参数。 我发现一个较老的讨论 ,该主题不令人满意。

例子

  • 带有查询参数的URL: http://some.where/thing?paramA = 1&paramB = 6542
  • 带有matrix参数的URL: http://some.where/thing; paramA = 1; paramB = 6542

乍一看matrix似乎只有优势:

  • 更具可读性
  • 在XML文档中不需要编码和解码“&”
  • 带“?”的url 在许多情况下不被caching; 带有matrix参数的URL被caching
  • matrix参数可以出现在path的任何地方,并不限于其结束
  • matrix参数可以有多个值: paramA=val1,val2

但是也有缺点:

  • 只有像JAX-RS这样的几个框架支持matrix参数
  • 当浏览器通过GET提交表单时,参数变成查询参数。 因此,对于同一个任务,最终会有两种参数。 为了不会混淆REST服务的用户并限制服务开发者的工作,在这个区域中总是使用查询参数会更容易。

由于该服务的开发人员可以select一个matrix参数支持的框架,唯一的缺点是浏览器默认创build查询参数。

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

重要的区别是matrix参数适用于特定的path元素,而查询参数作为一个整体应用于请求。 在对多个级别的资源和子资源进行复杂的REST风格的查询时,这将起到作用:

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

这真的归结为命名空间。 如果仅使用查询参数,则最终会得到类似“category_name”和“object_name”的参数,您将失去请求中参数的局部性所增加的清晰度。 另外,当使用像JAX-RS这样的框架时,所有的查询参数都会出现在每个资源处理器中,导致潜在的冲突和混乱。

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

– 重要的是要降级评论部分.–

我不确定matrixurl有什么大不了的。 根据TBL写的w3cdevise文章,这只是一个devise思路,明确指出它不是networking的一个特征。 在使用相关URL之类的东西时不会实现。 如果你想使用它,那很好; 没有标准的方法来使用它,因为它不是一个标准。 – Steve Pomeroy

所以简短的回答是,如果你需要RS作为商业用途,你最好使用请求参数。