我的设计公开了两种资源:

  1. 图片
  2. 标签

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

有帮助吗?

解决方案

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

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

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

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

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

    该 URI 充当集合中图像的随机调度程序;它返回一个 第303章看其他 响应,重定向到该集合的随机图像。 根据定义, ,这个 URI 一定不能被缓存,固定的 URI 应该被缓存,并且浏览器不应该理解到第二个资源的重定向是永久的,所以它是最佳的。

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

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

    此访问将导致 第300章 多项选择 回复;它将整个集合(作为 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 方式。

其他提示

我一直在这个问题上挣扎。我们最终实现的是 HttpResponseRedirect,例如:

http://www.example.com/randomNewYorkImage

随机的纽约图像:

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

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

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

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

您的资源是图像,因此这就是您的 URI。此外,特定图像具有永不改变的特定 URI。

您的“按标签”是资源的非识别属性。为此,可以使用查询字符串。

这是我的第一个想法。

  • http://www.example.com/MyStuff/image/ID/ -- 通过 id 指定特定图像
  • http://www.example.com/MyStuff/image/?tag=标签名 -- 带有给定标签的随机图像,隐式地, count=1.
  • http://www.example.com/MyStuff/image/?tag=标签名&count=all -- 具有给定标签的所有图像按随机顺序排列(count=1 是默认值,这会给你一个任意图像)

我会做类似的事情 http://foo.com/image/tagged/sometag/random 并停止为此失眠。

在这一点上我同意 Triptych 的观点。在某种程度上,将随机添加到 URI 的末尾让人感觉像是一个操作,但如果它的范围仅限于标签,那么您实际上只是在优化上下文。

在他的例子中:

/图像/标记/sometag/随机

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top