我们正在讨论如何设计 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，因此没有严格的技术限制，这实际上更像是一个哲学问题。
我环顾四周，在这类事情上找不到任何可靠的建议。
【问题讨论】：
标签： web-services rest
我遇到了同样的问题并选择了选项 2（每个资源一个“规范”URI），为了简单和可靠（每个根有一个 类型的资源）。
否则，你什么时候停下来？考虑：
/actors/
/actors/A
/actors/A/movies
/actors/A/movies/1
/actors/A/movies/1/actors
/actors/A/movies/1/actors/B
...
【讨论】：
从局外人的角度来看，我希望 movies/1/actors/A 为该电影返回特定于该演员的信息，而我希望 /actors/A 一般返回有关该演员的信息。
以此类推，我希望 projects/1/tasks/1/cmets 返回特定于任务的 cmets - 通过其 url 关系的最高级别。
我希望 projects/1/cmets 返回与较低级别项目相关的 cmets，或聚合项目中的所有 cmets。
这个类比并不特定于所讨论的数据，但我认为它说明了导致对返回数据的某些期望的 url 层次结构点。
【讨论】：
在这种情况下，我显然更喜欢/actors/A。
我的理由是，/movie/1/actors 报告了一个列表。这个列表是电影和演员之间的 1-n 映射，不能成为具有更多节点的路径。 人们根本不希望在电影树中找到演员。
您可能有一天会实现 /actors/A/movies 返回 1 和 2，这将使您实现像 /actors/A/movies/2 这样的 URL - 在这里您会得到 递归：movie/actor/movie/actor。
我希望每个对象只有一个 URL，以及一个可以找到 1-n 映射的清晰位置。
【讨论】：