在这里工作时，我们有一个框向业务合作伙伴提供 XML 提要。对我们的提要的请求是通过指定查询字符串参数和值来定制的。其中一些参数是必需的，但很多不是。
例如，我们要求所有请求都指定一个 GUID 来标识合作伙伴，并且请求可以是“获取最新”或“搜索”操作:
搜索: http://services.null.ext/?id=[GUID]&q=[Search关键字]
类别中的最新数据: 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 重写的特定技术。)
最佳答案
您应该在查询字符串中保留可选的查询参数。 REST 中没有规定不能有查询字符串的“规则”。实际上，情况恰恰相反。查询字符串应用于更改您正在传输回客户端的表示的 View 。
坚持为您的 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 .它很旧，但可能会有所帮助。
关于http - REST 化 URL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/168557/