非实体资源能否创建REST API端点？薪资日记后端优化咨询

完全合理，甚至是推荐的做法，核心原因如下：

• 减轻客户端负担：把按月/日分组、筛选payment/deduction这类聚合逻辑从前端移到后端，能直接减少React组件的计算量，避免组件过载，同时规避前端处理大量数据时可能出现的渲染卡顿、响应延迟等性能问题。
• 降低网络传输成本：后端返回已聚合、筛选完成的WorkingMonth结构化数据，相比返回全量entries实体，能大幅削减传输的数据体积，提升接口响应速度。
• 实现逻辑复用与统一：如果后续新增移动端、管理后台等其他客户端，后端的WorkingMonth服务可直接复用聚合筛选逻辑，避免多端重复开发相同规则，降低长期维护成本。
• 保障数据一致性：聚合逻辑由后端统一处理，能彻底避免不同客户端因实现差异导致的数据展示不一致问题。

落地时可以注意几个细节：

• 定义清晰的WorkingMonth数据结构，包含月维度汇总信息（如当月总薪资、总扣款）、按日分组的条目列表，以及筛选后的payment/deduction明细。
• 支持动态参数（如指定年月、筛选特定条目类型），让API具备更强的灵活性。
• 可加入缓存策略，缓存已生成的WorkingMonth数据，避免重复计算相同年月的聚合结果，进一步优化性能。

内容的提问来源于stack exchange，提问作者kirill reut