【发布时间】:2010-09-28 21:48:02
【问题描述】:
我的设计暴露了两种资源:
- 图片
- 标签
我希望客户能够通过他们的标签请求随机图像。例如:给我随机的带有“纽约”和“冬天”标签的图片。在这种情况下,RESTful 设计会是什么样子?
【问题讨论】:
我的设计暴露了两种资源:
我希望客户能够通过他们的标签请求随机图像。例如:给我随机的带有“纽约”和“冬天”标签的图片。在这种情况下,RESTful 设计会是什么样子?
【问题讨论】:
多维资源识别具有挑战性。
您的资源是一张图片,所以这就是您的 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 是默认值,它会给你一个任意图像)【讨论】:
我一直在努力解决这个问题。我们最终实现的是一个 HttpResponseRedirect,例如:
http://www.example.com/randomNewYorkImage
随机纽约图片:
http://www.example.com/images/New_York/1234.
第一个资源可以设想为一个随机的纽约图像调度程序。此解决方案将加载更多的服务器,因为它会被请求两个资源,但它是尽可能 RESTful 的。
编辑:另外,如果您正在缓存,每个图像都将在缓存中,并且您的服务器从发送图像变为仅发送重定向,因为缓存将拦截第二个请求,从而减轻您的服务器负载。
【讨论】:
我会做类似http://foo.com/image/tagged/sometag/random 之类的事情,并且不会因此而失眠。
【讨论】:
我同意三联画的这一点。在某种程度上,将随机添加到 URI 的末尾会让人感觉像是一个操作,但如果它的作用域是标签,那么你实际上只是在优化上下文。
在他的例子中:
/image/tagged/sometag/随机
图像资源 -> 标记范围(所有带有标签的图像)-> 特定标签(所有带有标签 X 的图像)-> 随机(来自带有标签 X 的图像范围列表中的资源)
【讨论】:
为了总结 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。
【讨论】: