技术问询：复杂度处理责任归属——简单CRUD端点vs复杂端点

这事儿我太有共鸣了！最近和前端同事刚好就「系统复杂度该放在后端还是前端」掰扯了半天，核心争议就是：到底是后端新增整合多个简单端点的复杂接口，还是由前端调用多个独立的简单端点？ 我们围绕两个具体业务场景展开了讨论，各持己见没达成结论，来拆解下双方的逻辑：

案例1：API密钥再生操作 #

• 我的立场：前端分别调用DELETE /api/keys/{id}（删除旧密钥）和POST /api/keys（创建新密钥）两个端点完成再生。尤其考虑到未来要支持「单用户多密钥」的需求，拆分的接口灵活性更强——比如以后用户可以单独删除某一个旧密钥、批量新增多个新密钥，不用被一个固定的「再生」接口限制死逻辑。
• 同事的立场：必须把这两个操作整合为一个POST /api/keys/regenerate端点。核心顾虑是事务一致性：如果第一步删除旧密钥成功，但第二步创建新密钥失败，用户会陷入「没有可用密钥」的异常状态，而整合接口可以在后端做事务控制，失败时自动回滚删除操作，避免数据异常。

案例2：用户注册时创建嵌套关联对象（Parent⮑Child⮑GrandChild） #

• 我的立场：前端依次调用三个CRUD端点：POST /api/parents、POST /api/children（关联Parent ID）、POST /api/grandchildren（关联Child ID）。拆分的接口符合RESTful的单一职责原则，每个端点只负责一个资源的操作，后续维护和扩展更清晰——比如以后单独修改Child资源的创建逻辑，完全不用动整个注册流程的接口。
• 同事的立场：同样担心分步操作的数据不一致风险：如果Parent和Child创建成功，但GrandChild创建失败，会导致数据库里出现「无后代的Parent/Child」脏数据，后端必须提供一个原子化的整合接口，保证三个操作要么全部成功，要么全部回滚。

背后的核心权衡点 #

其实双方的逻辑都站得住脚，本质是**「扩展性/复用性」和「数据一致性/事务安全性」**的优先级选择：

• 如果团队更看重长期的接口扩展性和复用性，拆分端点是更优解，但前端需要承担分步调用的异常处理成本——比如某一步失败后给用户明确提示，或者做简单的补偿逻辑；
• 如果业务对数据一致性要求极高，且异常场景的处理成本远高于接口复杂度，那么后端提供整合接口更稳妥，但要做好接口的版本控制，避免未来需求变化时接口逻辑过于臃肿。

内容的提问来源于stack exchange，提问作者Edgar.A