简单模型：
产品，有重量（可混合 - 盎司，克，千克等）
Cagtegories，其中有许多产品
REST端点：
/products - get all products and post to add a new one
/products/id - delete,update,patch a single product
/categories/id - delete,update,patch a single category
/categories - get all categories and post to add a new one
问题是前端客户想要显示所有类别中产品总重量的图表。想象一下条形图或饼图，显示所有类别，以及每种产品的总重量。
显然，产品型号具有“重量值”＆＃39;和一个'weight_unit＆＃39;所以你知道产品的重量及其尺寸（盎司，克等）。
我看到了解决这个问题的两种方法：
在类别模型中，添加一个计算字段，该字段总计一个类别中所有产品的权重。总计是针对该类别（未存储）即时计算的，因此始终是最新的。请注意，客户端始终需要所有类别（例如，在创建产品时填充下拉列表，您必须选择它所属的类别），因此它现在将自动始终具有每个类别的总重量。因此构建图表很简单 - 无需从服务器获取图表的数据，它已经在客户端上。但第一次加载数据可能会很慢。只有在添加产品时，总数才会过时（尽管总体数量变化不大，但无论如何陈旧总数都很好）。
创建一个单独的端点，比如categories / totals，它返回所有类别：类别ID，名称和总重量。该端点将循环遍历所有类别，计算每个类别的权重，并返回每个类别的权重的类别数据集。
我看到（1）的问题是它不是那么高效。我知道它的可扩展性不是很高，特别是当一个类别最终产生大量产品时（数百万！）但这是一个业余爱好项目，所以不用担心。
（1）的优点是您始终拥有客户端上的数据，并且不必单独请求获取图表的数据。
然而，（2）的优点是每个对category / id的请求都不会产生潜在的昂贵的总计操作（因为现在它位于自己的专用端点内）。当然，端点必须进行相当复杂的数据库查询才能计算所有类别的所有产品的权重（尽管将数据交给数据库的方式应该是db的优点！）< / p>
我真的很难过，这是更好的方法。哪种方式更适用于RESTful方式（基本上是HATEOS）？
答案 0 :(得分：1)
我会选择2.支持可伸缩性和最佳实践。每次请求类别时执行重量计算并没有任何意义，即使您可能没有预料到这是一个问题，因为它是一个“爱好”。项目，它总是最好避免捷径，其中的好处是最小的（或者经验告诉我！）。
选择1，唯一的好处是你必须设置一个较少的端点和一个额外的调用来获得总重量 - 额外的调用不应该增加太多的开销，并且设置额外的端点应该＆ ＃39; t需要付出太多努力。
无论您选择1还是2，我都会考虑缓存总重量（合理的时间，取决于所需的准确度），以进一步提高性能。