REST - 端点是不是应该包含摘要数据？

Posted 2023-02-19

【中文标题】REST - 端点是不是应该包含摘要数据？

【英文标题】：REST - should endpoints include summary data?REST - 端点是否应该包含摘要数据？

【发布时间】：2017-01-05 23:07:54

【问题描述】：

简单模型：

具有重量的产品（可以混合 - 盎司、克、公斤等）

类别，其中包含许多产品

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

问题是前端客户端想要显示所有类别中产品总重量的图表。想象一下显示所有类别的条形图或饼图，以及每个类别中产品的总重量。

很明显，产品型号有一个“weight_value”和一个“weight_unit”，因此您可以知道产品的重量及其度量（盎司、克等）。

我看到了两种解决方法：

在类别模型中，添加一个计算字段，该字段对类别中所有产品的权重进行合计。总数是针对该类别动态计算的（未存储），因此始终是最新的。请注意，客户端始终需要所有类别（例如，要在创建产品时填充下拉列表，您必须选择它所属的类别），因此它现在将自动始终拥有每个类别的总权重。所以构建图表很容易——不需要从服务器获取图表的数据，它已经在客户端了。但是第一次加载该数据可能会很慢。仅当添加产品时，总数才会过时（尽管总数的变化很小，但无论如何过时的总数都可以）。

创建一个单独的端点，例如类别/总数，它返回所有类别：类别 ID、名称和总权重。该端点将遍历所有类别，计算每个类别的权重并返回一个类别数据集，其中包含每个类别的权重。

我在 (1) 中看到的问题是它的性能不高。我知道它的可扩展性不是很好，尤其是当一个类别最终有很多产品（数百万！）但这是一个爱好项目，所以不用担心。

(1) 的优点是您始终拥有客户端上的数据，无需单独请求获取图表数据。

但是，(2) 的优点是每个对 category/id 的请求都不会导致潜在的昂贵的总计操作（因为现在它位于自己的专用端点内）。当然，该端点必须执行相当复杂的数据库查询来计算所有类别的所有产品的权重（尽管将其交给数据库应该是 db 擅长的方式！）

我真的很困惑哪种方法更好。哪种方式更符合 RESTful 方式（基本上是 HATEOS）？

【参考方案1】：

我会选择 2. 支持可扩展性和最佳实践。每次请求类别时执行权重计算实际上没有任何意义，即使您可能不会认为这是一个问题，因为它是一个“爱好”项目，但最好避免使用收益最小的捷径（或者经验告诉我！）。

选择 1，唯一的好处是您必须设置一个更少的端点和一个额外的调用来获得总重量 - 额外的调用不应该增加太多的开销，并且设置额外的端点不应该占用太多精力。

无论您选择 1 还是 2，我都会考虑缓存总重量（在合理的时间内，取决于所需的准确性）以进一步提高性能。

【讨论】：

感谢您对您的想法的合理解释。我的头被代码卡住了，看不到“树上的木头”。但是现在，在阅读了您的想法之后，我认为您是对的，并且选项 2 更好。现在选项 1 似乎是快速简便的出路，但实际上只是造成代码债务！

没问题！是的-代码债务是正确的词