论接口原子化和简单化的重要性

这篇文章咱们不说技术，而是来说说接口的设计，最近在做一个项目，遇到一个产品设计的问题，对前端的交互、后端实现带来很大的麻烦。在产品经理提出这样做的时候我就提出了很强的异议，但是技术经理觉得这样在技术上实现没有任何问题，最后只能屈服，完成这个功能的开发，现在随着版本的迭代，问题慢慢被放大，不但界面交互很low，后端数据存储和关联也隐藏了弊病。接下来就详细说一下这个过程，然后说说我对接口要原子化、简单化重要性的理解。

我们项目是这么做的

这里涉及到公司项目机密，内容不能外泄，这里我就以示文字描述来说。

废话不多说，这里先说功能：

• 在这个项目中有个产品的概念，每个产品都有自己的A列表、B列表、C列表
• 在操作界面中可以编辑A列表、B列表、C列表，这个编辑包含增删改操作
• 对这些列表一系列操作都是缓存到前端，然后由前端一次性提交到后端

这个功能算是常规操作，这个常规操作对后端是一个考验，因为前端提交是全量的，里面包含增、删、改三个操作，后端就需要进行复杂的判断操作。实现方式有两种。

第一种：先删再插

• 接收到提交请求后，将库中该产品中存在A、B、C列表数据全部清理(逻辑清理)
• 将前端提交来的数据全部直接插入数据库

这样就可以屏蔽增、删、改的检查逻辑，简单粗暴，但是这个是有问题的，后续来介绍。

第二种：逐步判断

• 接收到请求后，将库中该产品中存在的A、B、C列表全部查询出来
• 将前端提交的数据和存量数据依次对比判断，根据判断结果，确定是增、删、改中的哪个操作，然后做对应的操作

这样是对数据比较友好的操作，但是对开发人员是一种折磨，因为比对逻辑很复杂，特别是对于复杂的列表。如A列表中单个元素，然后元素内部又嵌套其他属性或元素，层层嵌套和关联。(我们项目就是这样)

两种方式都介绍完了，你觉得我们应该是选的那一种？以偷懒为第一准则，我们