Rest风格的API设计-将模型合并到一个资源中？

我的问题是什么时候可以将不同的模型合并到一个REST资源中，以及这是否会导致设计的复杂和困难

假设我有一个电影流媒体服务，用户只能观看他们有权限观看的电影类型。假设这些是用这些假设模型表示的：

用户id 电影类型id、类型名称 用户到类型权限id、类型id、用户id 通过REST路由/用户/电影类型和/用户到类型权限公开

现在，作为这个API的用户客户端，比如一个网站或一个移动应用程序，为了找出允许我获取的类型，我会获取类型权限，然后获取所有电影类型。两个网络电话

然而，有一种观点认为，必须对API进行多次往返是低效的，而且您还必须处理客户端上的大量连接。这个例子很简单，有3个关系，但在现实世界中，你可能会有更长的链

因此可以考虑将两个模型折叠为一个，例如已经返回到电影类型的返回权限：

电影类型id、类型名称、当前用户的授权

然而问题是，这个思考过程可以走得很远。通过在服务器上进行所有连接，可以为客户端节省大量连接和往返。然而，你在什么时候停下来？在什么情况下，您返回的不再是REST资源，而是连接在一起的通用数据块

是否有一个经验法则来决定在哪里划界？

REST代表代表性状态转移。从维基：

请求和响应是围绕数据传输构建的 资源的表示。资源基本上可以是任何资源 可以解决的连贯而有意义的概念。A. 资源的表示形式通常是捕获 资源的当前或预期状态

因此，RESTful web服务提供对资源的访问，这意味着任何API调用都应该集中在一个资源上——这应该是您的经验法则

---

您发布的示例非常基本，但是如果您要添加更多实体，例如：电影制作人、演员、媒体公司等，那么每个请求应该只处理一个实体。这就是说，您的后端将需要处理要求它运行连接的请求，例如，用户X的电影推荐。但不要让它迷惑您-请求应该非常简单，响应应该包括类型为movie的对象列表-只有一个实体

下面的链接提供了有关DB规范化的基础知识：alfasin，问题不在于DB端，而在于API客户端。可以安全地假设API客户机完全不知道API的内部结构，事实是您可以为每个底层连接创建单独的资源。演员在电影资源，制片人在电影资源等，你应该吗？你应该避免吗？有些人也选择通过嵌套资源来处理这个问题。如果您有一对多关系，那么您可能应该创建一个新表。如果是一对一，您可以在相关表中添加另一列。如果您决定使用未规范化的数据—选择会更容易，但维护会更复杂，即触发器、约束、事务等。您只需提供客户可能感兴趣的资源，而且，定义资源表示的模型不必与服务底层的业务模型完美匹配。我知道我应该在请求正文中对资源进行POST，以便添加连接关系，但我只想传递两个属性标识符，即它们的id，而不是两个整体属性对象，使之对客户更简单。