0

我有一个网络服务，允许我的用户管理音乐节。每个节日都有一个地点，几个舞台，每个舞台上都有几位艺术家。

所以我有 4 个实体：节日、地点、舞台和艺术家，可以表示为树形结构。我需要一个简单的 CRUD。

在 REST API 术语中，显而易见的实现是有 4 个 URI（/festivals、/locations、/stages 和 /artists，可能后跟 /id），这些 URI 将通过 POST、PUT、GET 或 DELETE 进行请求。

但是，根据我的需要，地点、舞台和艺术家如果不与节日相关联，就没有兴趣。那么为什么我需要为这些实体实现 CRUD 方法呢？仅针对节日实体的 CRUD 还不够吗？

缺点：

  • 我的 API 的客户端（网站、本地移动应用程序、其他服务......）无法读取我的节日的子实体。但是，正如我之前所说，我服务的子实体没有他们所属的节日就没有兴趣。因此，每个客户都必须获得节日、整个节日以及每个子实体。

  • 即使他们只是修改了艺术家的名字，这些客户也需要更新整个节日。这似乎是最糟糕的缺点，但毕竟，发送我的节日的完整 json（最大几 kb）而不是会更短的部分 json 有那么糟糕吗？

优势 ：

  • 我需要编写、测试和维护 4 种方法而不是 16 种方法（如果要管理的实体更多，假设它们保持这种简单的树形结构，甚至更多）。

从技术上讲，我将使用可爱的组合 node.js + mongodb 来执行此操作（它与情况没有太大关系，只是 mongodb 的超级树友好方面让我思考它）。

您如何看待这种方法？你看到这个想法的其他缺点吗？

4

1 回答 1

3

Your justification for having the smaller API looks sound. However, make sure you're also considering the complications of concurrent data access.

The larger the amount of data you package into a single unit, the more chances you have for change conflicts. For example, if you have two users modifying the same festival, one changing the stage name and the other changing an artist name, you could have a race condition where one update overwrites the changes made in the other. Obviously, you can have race conditions even if you have a more granular API, but merging everything into one unit amplifies the problem.

于 2012-06-19T00:34:02.633 回答