我有一个网络服务，允许我的用户管理音乐节。每个节日都有一个位置，几个阶段，每个舞台上有几位艺术家。
所以我有4个实体：节日，地点，舞台和艺术家，可以表示为树形结构。我需要一个简单的CRUD。
在REST API术语中，显而易见的实现是使用POST，PUT，GET或DELETE请求4个URI（/节日，/位置，/阶段和/艺术家，可能后跟/ id）。
但是，根据我的需要，地点，舞台和艺术家如果没有与节日联系，就没有兴趣。那么为什么我需要为这些实体实现CRUD方法呢？只有节日实体的CRUD应该不够？
缺点：
我的API的客户（网站，原生移动应用程序，其他服务......）无法读取我的节日的子实体。但是，正如我之前所说，如果没有他们所属的节日，我的服务的子实体就没兴趣了。因此，每个客户都必须参加节日，整个节日，以及每个子实体。
即使他们只修改了艺术家的名字，这些客户也需要更新整个节日。这似乎是最糟糕的缺点，但毕竟，发送我的节日的完整json（最大几kb）而不是那个会更短的部分json是不是很糟糕？
优点：
从技术上讲，我将使用可爱的组合node.js + mongodb这样做（除了它是mongodb的超级树友好方面让我考虑之外，它与情况没什么关系）。
您如何看待这种方法？你有没有看到这个想法的其他缺点？
答案 0 :(得分：3)
使用较小的API的理由看起来很合理。但是，请确保您还在考虑并发数据访问的复杂性。
您打包到一个单元中的数据量越大，您发生更改冲突的可能性就越大。例如，如果您有两个用户修改相同的festival，一个更改阶段名称而另一个更改艺术家名称，则可能会出现竞争条件，其中一个更新会覆盖另一个更改。显然，即使你有一个更细粒度的API，你也可以拥有竞争条件，但是将所有内容合并到一个单元中会放大这个问题。