1

我们正在讨论如何设计 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,它期望一定的层次结构 - 与不希望有多种方式访问​​相同数据的愿望(最终它实际上是少量的代码重复)。可以将 Ember.js 映射为使用 /actors/A,因此没有严格的技术限制,这实际上更像是一个哲学问题。

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

4

3 回答 3

4

为了简单和健全(每个根使用一种资源),我遇到了同样的问题并选择了选项 2(每个资源一个“规范”URI)

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

/actors/
/actors/A
/actors/A/movies
/actors/A/movies/1
/actors/A/movies/1/actors
/actors/A/movies/1/actors/B
...
于 2013-06-04T20:06:35.360 回答
3

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

以此类推,我希望 projects/1/tasks/1/comments 返回特定于任务的评论 - 通过其 url 的关系的最高级别。

我希望 projects/1/comments 返回与较低级别项目相关的评论,或汇总项目中的所有评论。

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

于 2013-06-04T20:05:27.263 回答
3

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

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

您可能有一天会实现/actors/A/movies返回 1 和 2,这将使您实现类似的 URL /actors/A/movies/2- 在这里您会得到递归:电影/演员/电影/演员。

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

于 2013-06-04T20:05:59.080 回答