Restful API创建多个关联依赖资源的异常处理及合规方案问询

针对你遇到的提前创建关联资源后主资源创建失败产生脏数据的问题，REST范式下有多种成熟的解决方案：

方案1：临时资源标记 + 过期清理 #

• 给User、File资源新增status状态字段，提前创建时标记为临时待绑定状态，同时设置默认有效期（比如15分钟）
• 调用POST /companies接口创建成功后，立刻调用更新接口将关联的User、File的状态改为已生效
• 后台新增定时任务，定期清理超过有效期的临时状态资源，就算公司创建失败，脏数据也会被自动回收
• 优点：完全兼容你现有的接口拆分逻辑，业务改造量小
• 缺点：需要额外开发状态字段和定时清理任务

方案2：聚合资源一次性提交（符合REST规范） #

你之前认为「请求体中直接携带文件和用户数组信息一次性创建所有资源不符合Restful规范」是常见的认知误区：

REST规范并没有要求单个请求只能操作单一类型的资源，聚合资源本身就是合法的资源表述形式。

你完全可以直接定义POST /companies接口的请求体支持嵌套的用户、文件完整参数，服务端开启本地事务，一次性完成User、File、Company三个资源的创建，任意环节出错就直接回滚所有操作，从根源上避免脏数据产生。

• 优点：逻辑最简单，可靠性最高，没有额外的状态管理、定时任务开销
• 缺点：需要调整现有接口的请求参数结构

方案3：失败补偿兜底 #

• 调用POST /companies创建失败时，服务端同步或者异步触发补偿逻辑，直接删除本次请求关联的User、File资源
• 也可以在返回创建失败响应时，告知前端关联的资源ID列表，由前端调用删除接口清理对应资源
• 优点：改造成本最低
• 缺点：可靠性差，出现网络异常等极端情况时容易出现补偿失败的问题

选型建议 #

• 如果业务逻辑没有强制要求User、File必须提前创建，优先选择方案2
• 如果需要支持用户提前上传文件预览、提前导入用户核对等场景，选择方案1
• 仅当你的系统是内部使用、前端逻辑完全可控的场景下，再考虑方案3

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