代码之家  ›  专栏  ›  技术社区  ›  core

重置URL

  •  7
  • core  · 技术社区  · 16 年前

    在这里,我们有一个向业务合作伙伴提供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/path,有哪些建议的实践?

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

    2 回复  |  直到 16 年前
        1
  •  4
  •   Pete    16 年前

    您应该在查询字符串中保留可选的查询参数。REST中没有“规则”表示不能有查询字符串。实际上,情况恰恰相反。查询字符串应用于更改要返回到客户机的表示形式的视图。

    对于URL路径组件,请坚持使用“具有可表示状态的实体”。类别似乎还可以,但您究竟在向XML提供什么?帖子?目录项?部分?

    我认为更好的REST分类法应该是这样的(假设XML提要的内容是一篇“文章”):

    如果您在构建REST结构时没有考虑您所表示的实体,那么您就不会进行REST。你在做别的事情。

    看一看 this article on REST best practices . 它很旧,但可能有帮助。

        2
  •  1
  •   Jonathan Arkell    16 年前

    参数值?一个选项是查询字符串。使用它并不是天生的不安分。另一种选择是使用分号, Tim Berners-Lee talks about them 而且他们可能只需要满足这个要求,允许URL合理化,而不需要走太长的路。