题
在这里,我们有一个向业务合作伙伴提供 XML 提要的盒子。对我们的 feed 的请求是通过指定查询字符串参数和值来定制的。其中一些参数是必需的,但许多参数不是必需的。
例如,我们要求所有请求指定一个 GUID 来识别合作伙伴,并且请求可以是“获取最新”或“搜索”操作:
对于搜索: http://services.null.ext/?id=[GUID]&q=[搜索 关键词】
类别中的最新数据: http://services.null.ext/?id=[GUID]&category=[ID]
为这些参数构建 RESTful URL 方案很简单:
搜索: http://services.null.ext/[GUID]/search/[关键字]
最新的: http://services.null.ext/[GUID]/latest/category/[ID]
但是我们应该如何处理我们拥有的十几个可选参数呢?其中许多是相互排斥的,并且许多需要组合使用。很快,可能的路径数量就会变得极其复杂。
对于如何将具有复杂查询字符串的 URL 映射到更友好的 /REST/ful/paths,有哪些推荐做法?
(我对约定、方案、模式等感兴趣。不是在 Web 服务器或框架中实现 URL 重写的特定技术。)
解决方案
您应该在查询字符串中保留可选的查询参数。REST 中没有“规则”表明不能有查询字符串。事实上,情况恰恰相反。查询字符串应用于更改您传输回客户端的表示的视图。
对于 URL 路径组件,请坚持使用“具有可表示状态的实体”。类别看起来不错,但是您通过 XML 提供的到底是什么?帖子?目录项目?部分?
我认为更好的 REST 分类法如下所示(假设 XML feed 的内容是一篇“文章”):
- http://myhost.com/PARTNERGUID/articles/latest?criteria1=value1&criteria2=value2
- http://myhost.com/PARTNERGUID/articles/search?criteria1=value1&criteria2=value2
如果您在构建 REST 结构时没有考虑您所代表的实体,那么您就没有在进行 REST。你正在做别的事情。
看一眼 这篇关于 REST 最佳实践的文章. 。它很旧,但可能会有所帮助。
其他提示
带值的参数?一个选项是查询字符串。使用它本身并不是非常安宁。另一种选择是使用分号, Tim Berners-Lee谈论它们和他们可能只是适合账单,允许URL有意义,而不需要很长的路径。