重新生成网址

Question

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

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

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

构建这些参数REST风格的URL方案很简单：

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

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

有关如何将URL与复杂查询字符串映射到friendlier/REST/ful /路径的一些推荐做法？

（我感兴趣的约定，计划，图案等不执行URL重写Web服务器上或在一个框架的具体技术。）

Answer 1

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

坚持“具有可表示状态的实体”作为URL路径组件。分类似乎没问题，但是你对XML的反馈究竟是什么？帖子？目录项目？部分？

我想一个更好的REST的分类应该是这样的（假设你的XML饲料的内容是 “文章”）：

• http://myhost.com/PARTNERGUID/articles/latest?criteria1=value1&criteria2=value2
• http://myhost.com/PARTNERGUID/articles/search?criteria1=value1&criteria2=value2

如果”在构建REST结构时，不要考虑你所代表的实体，你不会做REST。你在做别的事情。

看看this article on REST best practices。这是旧的，但它可能有帮助。

Answer 2

参数与价值？一个选项是查询字符串。使用它并非天生不安宁。另一种选择是使用分号Tim Berners-Lee talks about them，它们可能只是适合账单，从而使URL有意义，而不需要很长的路径。