在这里的工作中，我们有一个为业务合作伙伴提供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 / [关键字]
最新：http：//services.null.ext/ [GUID] / latest / category / [ID]

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

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

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

解决方案

带值的参数？一种选择是查询字符串。使用它并不是天生就不会烦躁。另一个选择是使用分号，Tim Berners-Lee谈论它们，它们可能恰好符合要求，从而使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最佳实践的这篇文章。它很旧，但可能会有所帮助。