1

我的问题是何时可以将单独的模型合并到一个单一的 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 资源，而是连接在一起的通用数据块？

是否有决定在哪里画线的经验法则？

4

1 回答 1

0

REST 代表Representational State Transfer. 来自维基：

请求和响应是围绕资源表示的传输构建的。资源本质上可以是可以解决的任何连贯且有意义的概念。资源的表示通常是捕获资源当前或预期状态的文档。

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

您发布的示例非常基本，但是如果您要添加更多实体，例如：电影制片人、演员、媒体公司等，那么每个请求应该只处理一个实体。也就是说，您的后端将需要处理需要它运行 JOIN 的请求，例如，为用户 X 推荐电影。但不要让它让您感到困惑 - 请求应该非常简单，并且响应应该包含一个“列表”类型的对象movie（只有一个实体！）。

于 2013-08-16T22:00:39.713 回答