我的设计暴露了两种资源:
我希望客户能够通过他们的标签请求随机图像.例如:给我标记为"纽约"和"冬季"的随机图像.在这种情况下,RESTful设计会是什么样子?
总结评论中的所有讨论,而不是改变我最初的建议,这就是我最后提出的:
您想通过标签访问图像;每个标签都与一组图像相关。由于给定标签的使用次数可能比另一个标签多得多(例如,纽约照片的使用次数比芝加哥的多得多),您应该使用允许缓存的 RESTful 配置,以便您可以缓存纽约照片。恕我直言,解决方案是:
每个图像都有一个固定的 URI:
http://www.example.com/images/12345
Run Code Online (Sandbox Code Playgroud)每个标签还有一个 URI:
http://www.example.com/tags/New_York/random
Run Code Online (Sandbox Code Playgroud)
此 URI 充当集合中图像的随机调度程序;它返回303 See Other响应,重定向到该集合的随机图像。根据定义,这个 URI 不能被缓存,固定的应该被缓存,浏览器不应该理解到第二个资源的重定向是永久的,所以它是最佳的。
您甚至可以通过以下方式访问整个集合:
http://www.example.com/tags/New_York
Run Code Online (Sandbox Code Playgroud)
此访问将导致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.
Run Code Online (Sandbox Code Playgroud)因此,您有每个图像的固定 URI,每个标签及其相关照片集的固定 URI,以及每个标签具有的随机调度程序的固定 URI。您不需要像其他潜在解决方案一样使用任何 GET 参数,因此这是您可以获得的 RESTful。
归档时间: |
|
查看次数: |
1553 次 |
最近记录: |