7

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

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

对于搜索：http://services.null.ext/?id=[GUID]&q=[搜索关键字]
类别中的最新数据：http://services.null.ext/?id=[GUID]&category=[ ID]

为这些参数构建 RESTful URL 方案很容易：

搜索：http://services.null.ext/[GUID]/search/[Keywords]
最新：http://services.null.ext/[GUID]/latest/category/[ID]

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

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

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

4

2 回答 2

4

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

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

我认为更好的 REST 分类法看起来像这样（假设您的 XML 提要的内容是“文章”）：

If you're not thinking about the entities you are representing while building your REST structure, you're not doing REST. You're doing something else.

Take a look at this article on REST best practices. It's old, but it may help.

于 2008-10-03T20:15:06.597 回答
1

带值的参数？一种选择是查询字符串。使用它并不是天生就让人不安。另一种选择是使用分号，Tim Berners-Lee 谈到了它们，它们可能正好符合要求，允许 URL 有意义，而无需大量长路径。

于 2008-10-03T20:11:38.553 回答