我的问题是什么时候可以将单独的模型合并到一个单独的REST资源中，以及这是否会导致棘手且难以使用设计，就行了。
假设我有电影流媒体服务，用户只能观看他们有权限的电影类型。假设用这些假设模型表示这些：
users (id) movie_genres (id, genre_name) users_to_genres_permissions (id, genre_id, user_id) 通过REST路由/users /movie_genres和/users_to_genres_permissions
现在，作为此API的用户客户端（想想一个网站或一个移动应用程序），为了找出我可以获取的类型，我会获取类型权限然后所有电影类型。两个网络电话。
然而，可以提出一个论点，即必须多次往返API是无效的，而且你还需要处理客户端上的一堆连接。这个例子很简单，有3个关系，但在现实世界中你可以有更长的链。
因此可以考虑将两个模型合并为一个，例如已经加入电影类型的返回权限：
movie_genres (id, genre_name, authorized_for_current_user)
然而问题是，这个思维过程可以采取相当远的方式。您可以通过在服务器上进行所有连接来为客户端节省大量的连接和往返。但是，你什么时候停止？您返回的资源不再是REST资源，而是连接在一起的通用数据块？
是否有一条经验法则可以决定画线的位置？
答案 0 :(得分：0)
REST代表Representational State Transfer。来自wiki：
请求和响应是围绕转移而构建的 资源的表示。资源基本上可以是任何资源 可以解决的连贯而有意义的概念。一个 资源的表示通常是捕获的文档 资源的当前或预期状态。
因此，RESTful Web服务提供对资源的访问，这意味着任何API调用都应该集中在一个资源上 - 这应该是您的“经验法则”。
您发布的示例非常基本，但如果您要添加更多实体，例如：电影制作人，演员，媒体公司等，则每个请求只应处理一个实体。也就是说，你的后端需要处理要求它运行JOIN的请求，例如，用户X的电影推荐。但是不要让它混淆你 - 请求应该非常简单，响应应该包括“列表” movie类型的对象（只有一个实体！）。