RESTAPI数据库结构

我正在构建一个简单的RESTAPI，其中包含book和bookCategory。 它们的特性非常简单且相同：

book {id, name, created_at, modified_at }
bookCategory {id, name, created_at, modified_at }

如果我只有这张桌子，我会像这样离开，但我对电影、绘画、视频游戏等都有相同的逻辑和结构。 即使它们具有相同的结构，但逻辑上是不同的，将它们拆分为不同的表是否是一种良好的做法。 我可以这样做，从而节省了大量的表格、控制器和表单，使其保持干燥：

things {id, **parent_id**, name, created_at, modified_at, **type** }

一些例子

它非常紧凑，但是对于所有电影类别或所有类别来说，它看起来像是一个端点吗

domain/api/things/???

---

或者最好是设置一个灵活的地面结构，也许会出现新的属性？

考虑到您定义的问题空间，使用垂直表是合理的-假设您预计不会有一个实体特有的新属性，例如“writer”，它可能出现在书本和电影上，但不是图书类别或电影类别。如果您预期新的独特属性或不确定，我建议为每个属性单独设置表。虽然您现在违反了DRY，但以后更改的成本将是巨大的

至于端点

GET /api/movieCategories
<- an entity with all movie categories

GET /api/movieCategories
<- an entity with all movie categories

GET /api/categories?type=movie