在这里工作时，我们有一个向业务合作伙伴提供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 /路径的一些推荐做法？
（我对约定，方案，模式等感兴趣。不是在Web服务器或框架中实现URL重写的特定技术。）
答案 0 :(得分：4)
您应该在Query字符串中保留可选的查询参数。 REST中没有“规则”表示不能有查询字符串。实际上，情况正好相反。应使用查询字符串来更改要传输回客户端的表示形式的视图。
坚持使用“具有可表示状态的实体”作为您的URL路径组件。类别似乎没问题，但究竟是什么让你在使用XML？帖子？目录项目？部分？
我认为更好的REST分类法看起来像这样（假设您的XML Feed的内容是“文章”）：
如果您在构建REST结构时没有考虑要表示的实体，那么您就不会使用REST。你正在做别的事。
看看this article on REST best practices。它已经过时了，但它可能有所帮助。
答案 1 :(得分：1)
带值的参数？一个选项是查询字符串。使用它本身并不是非常安宁。另一种选择是使用分号Tim Berners-Lee talks about them，它们可能只适合账单，允许URL有意义，而不需要很长的路径。