从性能角度看，RESTAPI URL设计仅针对单个属性

我正在开发RESTAPI和前端作为微服务。我知道URL设计的一些基本原则，但是有一个性能问题，我不知道如何处理它

为了方便显示网页，我想获得一些关于每页100多个资源的信息。（实际上，BFF作为业务流程层存在）

由于目标资源包含大量数据库记录的聚合结果，因此每个请求大约需要3秒钟。然而，我想在网页上看到的信息只是其中的一部分，不需要复杂的聚合就能得到，这使得响应时间大大缩短

以一个案例为例

有一个

article

的资源，返回

articles/:id

中包含复杂聚合的资源数据。但在本例中，我只需要一个注释计数，可以通过发出SQL

count

语句而不需要计数器缓存来快速获得

然而，在研究RESTAPI设计时，我从未见过GET请求只返回特定字段的情况

在微服务中，API应该只在松散耦合的情况下返回资源状态，所以我认为它不应该关注特定的字段

---

面对性能问题，可以考虑哪种URL设计或性能优化？

REST是万维网的架构风格；20世纪90年代，风格和网络并行发展。考虑到当时的使用模式和技术限制，样式的注意力更多地集中在大粒度文档的缓存上，而不是试图减少传输延迟

因此，您更有可能设计您的表示，以便count出现在表示中的某个位置，并且可以寻址到您可以引起注意的位置。因此：

因此，如果您已经有了一个标识符为

/articles

的资源，并且注释计数非常重要，那么您可以将表示形式视为DTO（），只需将注释计数包含在表示形式中，通过一些标识符（如

/articles#comment count

进行访问）

这不一定非常适合您的用例

另一种方法是只引入一个独立的注释计数资源

任何可以命名的信息都可以是资源--

如果你真的在做REST，那么URI的拼写就无关紧要了（想想——你最后一次关心google搜索表单在哪里提交了你的查询是什么时候？）。标识符用作标识符，通用客户机不尝试从标识符中提取语义

因此，使用

/d8a496c4-51c5-4eeb-8cbd-d5e777cbdee7

作为注释计数的标识符应该“起作用”

当然，它对人类读者不是特别友好，所以你可能更喜欢别的东西。从这个意义上讲，URI设计非常类似于选择一个好的变量名——机器不在乎，所以我会做出更易于人类管理的选择。这通常意味着选择与API中其他拼写“一致”的拼写

介绍路径、查询和片段之间的区别，您可以期望通用组件理解这些区别；潜在的重要区别之一是描述了通用组件如何从基本uri和相对引用计算新标识符

/articles/comment-count + ./1 -> /articles/1