设计存在重复数据的 REST 层次结构

Posted

技术标签:

【中文标题】设计存在重复数据的 REST 层次结构【英文标题】:Designing a REST hierarchy where there is duplicate data 【发布时间】:2013-05-31 08:31:39 【问题描述】:

我们正在讨论如何设计 REST 端点。它基本上归结为这个人为的例子。

假设我们有:

/netflix/movie/1/actors <- returns actors A, B and C
/netflix/movie/2/actors  <- returns actors A, D, and E

演员 A 是同一个演员。

现在要获取“更好”的演员的传记(是的,判断电话):

/netflix/movie/1/actors/A
/netflix/movie/2/actors/A

或:

/actors/A

分歧最终源于使用 Ember.js,它期望一定的层次结构 -vs- 不希望有多种方式来访问相同的数据(最终它确实是少量的代码重复)。可以将 Ember.js 映射为使用 /actors/A,因此没有严格的技术限制,这实际上更像是一个哲学问题。

我环顾四周,在这类事情上找不到任何可靠的建议。

【问题讨论】:

另见What are best practices for REST nested resources? 【参考方案1】:

我遇到了同样的问题并选择了选项 2(每个资源一个“规范”URI),为了简单和可靠(每个根有一个 类型的资源)。

否则,你什么时候停下来?考虑:

/actors/
/actors/A
/actors/A/movies
/actors/A/movies/1
/actors/A/movies/1/actors
/actors/A/movies/1/actors/B
...

【讨论】:

【参考方案2】:

从局外人的角度来看,我希望 movies/1/actors/A 为该电影返回特定于该演员的信息,而我希望 /actors/A 一般返回有关该演员的信息。

以此类推,我希望 projects/1/tasks/1/cmets 返回特定于任务的 cmets - 通过其 url 关系的***别。

我希望 projects/1/cmets 返回与较低级别项目相关的 cmets,或聚合项目中的所有 cmets。

这个类比并不特定于所讨论的数据,但我认为它说明了导致对返回数据的某些期望的 url 层次结构点。

【讨论】:

在这种情况下,这将是演员的传记作为一个整体,而不是特定于电影的任何内容。在实际应用程序的上下文中,从任一端点返回的数据没有区别。 那我绝对更喜欢演员/A。下面其他用户的回答涵盖了我所做的事情,即 /actors/A/movies/1/actors/B 的无尽字符串,这很奇怪。 资源只有一个 URI 对缓存很重要。【参考方案3】:

在这种情况下,我显然更喜欢/actors/A

我的理由是,/movie/1/actors 报告了一个列表。这个列表是电影和演员之间的 1-n 映射,不能成为具有更多节点的路径。 人们根本不希望在电影树中找到演员。

您可能有一天会实现 /actors/A/movies 返回 1 和 2,这将使您实现像 /actors/A/movies/2 这样的 URL - 在这里您会得到 递归:movie/actor/movie/actor。

我希望每个对象只有一个 URL,以及一个可以找到 1-n 映射的清晰位置。

【讨论】:

以上是关于设计存在重复数据的 REST 层次结构的主要内容,如果未能解决你的问题,请参考以下文章

Rest api 设计:使用重复数据创建 POST,可能是 IntegrityError/500,啥是正确的?

如何将具有重复字段值的表格数据转换为层次结构的 JSON?

在java中表示树层次结构[重复]

SSAS 维度层次结构:处理时发现重复的属性键

《Head First 设计模式》中组合迭代器重复打印的bug的两种解决方案

设计模式之原型模式