@fregie 这点其实我也是认同对方的，这样双方都轻松一些，后面开会对的时候明确好责任就好，有时候把事情简单化更难。

@rabbbit 嗯，我确实复杂化了。 不过我上面还有一层意思是，冗余设计覆盖到了我能想到的产品那边的未来需求：比如之后储存组件需求变化，大概率后端不需要任何调整（ e.g. 加个进度条，增删合并分区，安全弹出之类的），只是前端来调整对后端接口的使用就好。 不过反思了下我这种冗余设计确实不妥，相当于把 OS 的接口间接暴露给前端了，还是应该先等原型改完再定。

对方是有点咄咄逼人了，接口定义他要有异议提出来就行，再有分歧大不了拉个会再评审下。不过如果是在国内你用英文写文档就有点装了，什么术语能想不到中文啊。然后什么语法拼写错误的，真没有必要抓这些

我个人的习惯也是"轻前端",也就是只负责呈现,回收数据,所有必要的数据都由 api 准备好(api 职责单一,通过多个 api 组合使用完成业务) 这个事从结果来看,都能完成任务,从过程来说,就是个人偏好和团队偏好 就 OP 描述的事情来说,感觉不是纯技术输出,带点情绪

@unbinilium #12 看到你说 RESTful ，我就知道你领导说你过度设计是对的，这玩意过于理想化，在实际业务中强行使用，除了增加工作量，完全没有其他收益。内部系统，按照功能写接口才是最优的。我曾经跟领导有过这样的对话：“这个设计有问题，后面很难维护”，“这个功能都不知道会不会继续改，可能明年系统都下线了”。

你是不是还在实践 DDD ？

我最好奇的是，你们单位没有任何规范吗？比如我其实不喜欢 RESTFUL ，但是我们公司是明文规定要用 RESTFUL ，而且还有一堆细节设定，所以大家都得用。 如果没有明文规范，那以前的项目是哪种模式，照做就可以了。再不行，就问领导，让领导给意见。这种主观的东西，说到底看权力，没什么好争的。

@zacard 啊，我的问题，忘说了… 英文版对方没看，当时 review 的是我这边重新在他企业微信文档里补充的中文版，命名样式没来得及改成他定的规范，提前也说是主要看结构，样式尽快改好（我工作日常 linux ，企微跑在 qemu 里面确实不太好用） 拼写语法这些都是小问题，我从没提过，这里提一嘴是因为讨论时对方先批评了我，以及后面我理解他的文档十分费解。 @a33291 嗯，是有一点。当时临时 review 双方应该也是没想好，对面找我问题，我应该是没把我这边的设计思路用语言很好地传达给对方，表达能力还是太重要了。

经典的 API 设计一般要么贴近页面内容，要么贴近数据模型。 贴近页面的 API 一个 endpoint 对应一个页面，其优势在于前端只需要一次请求即可拿到全部需要的字段，加载/错误状态处理非常简单，字段数据按设计图填充即可，汇总拼装数据的工作主要在后端完成。这种方式的缺点在于页面内容是随产品迭代经常修改的，这意味着每次需求变更都需要变更接口数据结构以适配页面变化。如果要无缝升级，要么给 endpoint 加版本号，要么确保只新增字段不修改、删除现有字段。 贴近数据模型的设计一般每个 endpoint 对应一个数据库里的一个表，汇总拼装数据的工作由前端完成。这种方式的优点在于数据模型相对页面更稳定，受需求变更影响更少，而且真有变更大都是加字段的行为，比较容易向下兼容；缺点是前端需要组织从多个 endpoint 加载数据，管理它们之间的依赖顺序，记录跟踪每个请求的状态、错误处理等，前端复杂度会增加不少。

我随便一扯，你这长篇大论我只看了一半，我估计你设计的 api 也是这样