REST 化 URL

题

在这里，我们有一个向业务合作伙伴提供 XML 提要的盒子。对我们的 feed 的请求是通过指定查询字符串参数和值来定制的。其中一些参数是必需的，但许多参数不是必需的。

例如，我们要求所有请求指定一个 GUID 来识别合作伙伴，并且请求可以是“获取最新”或“搜索”操作：

为这些参数构建 RESTful URL 方案很简单：

但是我们应该如何处理我们拥有的十几个可选参数呢？其中许多是相互排斥的，并且许多需要组合使用。很快，可能的路径数量就会变得极其复杂。

对于如何将具有复杂查询字符串的 URL 映射到更友好的 /REST/ful/paths，有哪些推荐做法？

（我对约定、方案、模式等感兴趣。不是在 Web 服务器或框架中实现 URL 重写的特定技术。）

解决方案

您应该在查询字符串中保留可选的查询参数。REST 中没有“规则”表明不能有查询字符串。事实上，情况恰恰相反。查询字符串应用于更改您传输回客户端的表示的视图。

对于 URL 路径组件，请坚持使用“具有可表示状态的实体”。类别看起来不错，但是您通过 XML 提供的到底是什么？帖子？目录项目？部分？

我认为更好的 REST 分类法如下所示（假设 XML feed 的内容是一篇“文章”）：

如果您在构建 REST 结构时没有考虑您所代表的实体，那么您就没有在进行 REST。你正在做别的事情。

看一眼这篇关于 REST 最佳实践的文章. 。它很旧，但可能会有所帮助。

其他提示

带值的参数？一个选项是查询字符串。使用它本身并不是非常安宁。另一种选择是使用分号， Tim Berners-Lee谈论它们和他们可能只是适合账单，允许URL有意义，而不需要很长的路径。

许可以下： CC-BY-SA 和归因