【问题标题】:How to return random items RESTfully?如何RESTful返回随机项目?
【发布时间】:2010-09-28 21:48:02
【问题描述】:

我的设计暴露了两种资源:

  1. 图片
  2. 标签

我希望客户能够通过他们的标签请求随机图像。例如:给我随机的带有“纽约”和“冬天”标签的图片。在这种情况下,RESTful 设计会是什么样子?

【问题讨论】:

    标签: rest random


    【解决方案1】:

    多维资源识别具有挑战性。

    您的资源是一张图片,所以这就是您的 URI。此外,特定图像具有永远不会更改的特定 URI。

    您的“按标签”是资源的非识别属性。为此,查询字符串可能会发出声音。

    这是我的第一个想法。

    • http://www.example.com/MyStuff/image/id/ -- id 的具体图片
    • http://www.example.com/MyStuff/image/?tag=tagname -- 带有给定标签的随机图像,隐式为count=1
    • http://www.example.com/MyStuff/image/?tag=tagname&count=all -- 所有带有给定标签的图像以随机顺序排列(count=1 是默认值,它会给你一个任意图像)

    【讨论】:

    • 我认为如果每个标签都有一个 URI 会更加 RESTful(因为它是资源,虽然不是文件)。我看不太清楚的是标记集的随机顺序......
    • RESTful 很少涉及任何顺序规范(它可以,但很少见)。对于 SQL 查询,默认排序是随机的。这里也一样——默认顺序是随机的。
    • 好吧,我不知道在 SQL 中,但在 REST 中,集合的默认顺序可能是“无序的”,但不是特别随机(如果可以的话,足够随机,统计随机)。我的意思是,它不必像“同样的机会成为第一个”那样是随机的。
    • 再次,我建议将这个特定的 RESTful 资源集合明确定义为“随机”。而且,这与 SQL 兼容,所以有先例。
    • 哦,好的,对不起。我理解你说它是在 REST 中定义的,而不是“为了方便起见我们会这样定义”。我的错!
    【解决方案2】:

    我一直在努力解决这个问题。我们最终实现的是一个 HttpResponseRedirect,例如:

    http://www.example.com/randomNewYorkImage

    随机纽约图片:

    http://www.example.com/images/New_York/1234.

    第一个资源可以设想为一个随机的纽约图像调度程序。此解决方案将加载更多的服务器,因为它会被请求两个资源,但它是尽可能 RESTful 的。

    编辑:另外,如果您正在缓存,每个图像都将在缓存中,并且您的服务器从发送图像变为仅发送重定向,因为缓存将拦截第二个请求,从而减轻您的服务器负载。

    【讨论】:

    • 缓存一个随机图像是疯狂的,因为你不应该期望它会很快再次被请求。因为它是随机的。
    • 假设一个被数百万人使用的 Web 应用程序显示一组图像中的一个图像,例如,三个图像。举个例子,典型的公司网站上典型的 We-Love-Working-Here。你不会缓存它吗?
    • 假设一个 Web 应用程序有数千个用户请求数百万个随机图像。然后缓存,你的缓存就会中断。
    • 那么,您认为当您的网页太大时您不会缓存?图像不需要在所有访问中都是随机的。也许还有其他的观点可以得到一个具体的形象。也许,正如在示例中所评论的那样,有标签;如果纽约标签被大量访问,您可以缓存。但最
    • 因为,您知道,图像可以随机访问这一事实并不意味着它不能以其他方式访问;在这种情况下,为非随机方法缓存它是有意义的,并让随机方法有机会使用缓存而不是使用动态服务器。
    【解决方案3】:

    我会做类似http://foo.com/image/tagged/sometag/random 之类的事情,并且不会因此而失眠。

    【讨论】:

    • 你怎么能缓存随机资源?
    • 然后,您最终将通过重复请求缓存 Web 服务器上的每个图像。
    • 回想一下:图像可能由于另一个原因被缓存:在这种情况下,缓存将使用缓存副本。无论如何,缓存的职责,而不是您的职责,是确定要缓存的内容和不缓存的内容 - 至少您应该给它机会。
    【解决方案4】:

    我同意三联画的这一点。在某种程度上,将随机添加到 URI 的末尾会让人感觉像是一个操作,但如果它的作用域是标签,那么你实际上只是在优化上下文。

    在他的例子中:

    /image/tagged/sometag/随机

    图像资源 -> 标记范围(所有带有标签的图像)-> 特定标签(所有带有标签 X 的图像)-> 随机(来自带有标签 X 的图像范围列表中的资源)

    【讨论】:

    • 该解决方案的问题在于它没有将 URI 与固定图像链接,因此,除其他外,您无法缓存它。
    • 当然你不能直接缓存这个URI——你要求的是一个随机的图像。如果您想考虑缓存,请求此资源可以将 HTTP 302 重定向到可缓存的 URI(如本例中真正的权威图像资源)。
    • @revolution,缓存仍然没有意义,因为您不应该期望很快再次请求随机访问的图像。
    • 取决于图片数量和请求数量;作为一个固定的 URI,它可以被许多客户端使用。
    【解决方案5】:

    为了总结 cmets 中的所有讨论,而不是为了改变我最初的建议,这是我最终提出的:

    您想通过标签访问图像;每个标签都与一组图像相关。由于给定标签的使用量可能比另一个标签多得多(例如,纽约照片的使用量比芝加哥的多得多),您应该使用允许缓存的 RESTful 配置,这样您就可以缓存纽约的照片。恕我直言,解决方案是:

    • 每张图片都有一个固定的 URI:

      http://www.example.com/images/12345
      
    • 每个标签也有一个URI:

      http://www.example.com/tags/New_York/random
      

      此 URI 充当集合中图像的随机调度器;它返回一个303 See Other 响应,重定向到集合的随机图像。 By definition,这个URI不能被缓存,固定的应该,浏览器不应该理解重定向到第二个资源是永久的,所以它是最优的。

    • 您甚至可以通过以下方式访问整个集合:

      http://www.example.com/tags/New_York
      

      此访问将导致300 Multiple Choices 响应;它将整个集合(作为 URI,而不是图像!)返回给浏览器,由浏览器决定如何处理它。

    • 你也可以使用各种标签的交集:

      http://www.example.com/tags/New_York/Autumn/Manhattan/random
      http://www.example.com/tags/Autumn/Manhattan/New_York/random (equivalent to the previous one)
      http://www.example.com/tags/New_York/girls/Summer/random
      etc.
      

    因此,每个图像都有一个固定的 URI,每个标签及其相关的照片集都有一个固定的 URI,每个标签具有的随机调度程序都有一个固定的 URI。您不需要使用任何 GET 参数作为其他潜在的解决方案,因此这是您可以获得的 RESTful。

    【讨论】:

    • 我喜欢您对返回码 300 和 303 的使用,但我发现您的解决方案存在以下问题:1) 我希望 New_York/random 返回多个随机图像。我想你可以通过返回带有禁用缓存的标头的 HTTP 300 来解决这个问题。
    • 2) 我不喜欢 /tags/New_York/girls/Summer/random 因为斜线应该代表等级划分。 /tags;name=New_York;name=girls;name=Summer/random 从技术角度来看似乎更正确。
    • 吉利,解决方案没有你暴露的问题。如果您想要一个每次返回不同图像的 URI,303 可以工作,并且根据其定义,图像不会被缓存到 /random URI,而是被重定向到重定向的 URI。如果您希望 URI在单个请求中返回各种图像
    • 那么 300 将传递他们的 URI。
    • 您在 2) 中提出的建议在技术上并不正确;实际上,以弱方式使用 RESTful 是一种变通方法。如果您选择该路径,您不妨使用 GET 参数,这些参数正是为此目的而存在的 :)
    猜你喜欢
    • 2010-12-24
    • 2012-06-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-08-01
    相关资源
    最近更新 更多