1.5　从Mock服务到API管理平台

Mock服务虽然满足了前端工程师在开发阶段对模拟数据的需求，但一个显而易见的问题就是接口文档通常是由后端开发者维护的，每当接口发生变化时，后端都需要手动更新Mock服务中相应的模板代码，这种方式非常低效且容易出错。在现代化前端的工程基础建设中，我们更希望Mock数据的模板能够自动同步接口文档的变动，如果前端工程使用了TypeScript进行开发，那么后端可能还需要编写大量的接口类型定义代码，其所包含的信息本质上与接口文档是一致的，事实上，接口文档、TypeScript接口定义和Mock.js数据生成模板都可以看作接口定义的一种描述形式，这就意味着它们之间可以相互转换，甚至前后端用来组装符合接口要求的数据格式时所编写的代码也可以看作接口的表现形式。那么我们是否能够使用一种抽象度更高的语法来描述接口，然后通过实现转换器插件的方式来满足不同场景的需求呢？当然是可以的，这正是“适配器模式”所提倡的代码组织方式，这样的设计也符合软件设计的“开放封闭原则”，当以后有其他基于接口信息的描述形式出现时，只需要添加新的转换器就可以了。

如果我们从软件工程的角度来看待编程这件事情，就会发现它其实与工业生产活动高度类似，其本质上都是将原本依赖于人的作业过程逐渐调整为依赖于自动化、智能化的工具，从而持续获得更加稳定和可靠的结果，意识到“软件开发是一项持续进行的活动”是高手的基本素养。

这里举个例子来说明一下，假设你已经搭建了一个API管理平台，开发者只需要在网页上通过可视化的方式创建新的API，在页面内就可以同时得到Mock.js数据模板、JSON格式的接口定义和TypeScript接口类型的声明，用户只需要复制粘贴就可以得到需要的代码，从功能上来说，它的确已经实现了API一致性的需求，然而在真实的开发场景中，接口细节往往会被频繁更新，可能是后端开发者在开发过程中发现之前的设计不合理，于是修改了接口细节；可能是文档中声明某个字段是数字类型，但实际联调时接口却下发了字符串类型的数据；也可能是真实的接口中某个字段的拼写错误，这时虽然程序不会报错，但就是读取不到需要的数据等，各种各样的低级错误可能会造成大量的时间浪费。

如果仅仅向外归因，你可以说后端开发者不够细心，但这对于解决问题几乎没有任何帮助，即使后端开发者真的意识到自己的问题而有所改善，这样的改变也是不稳定的，谁能保证自己一直不犯错呢？如果换个角度来看，这个问题的本质其实在于我们最初设计的API管理平台只解决了API文档化和Mock能力集成等一些开发阶段的诉求，并没有实现包含更新、发布、测试、下线、统计等完整的生命周期管理能力，所以才会在修改和更新接口时产生大量的问题。更有效的做法是扩展平台的能力，从而减轻使用者的心智负担，这里提供一个功能更为完善的设计方案，如图1-1所示。

图1-1　一种接口管理服务的架构设计方案

在此方案中，后端工程师批量更新接口、推送代码并合并到指定分支后，提前在代码仓库中配置的hook消息就会生效，它能够通知其他服务某个分支的代码有变更，收到消息的服务只需要在自动化脚本中执行“git clone”命令就可以获取最新的API信息，当然也可以获取其他代码仓库中的代码，这时能做的事情就非常多了，比如拉取前端代码，根据新的API信息更新TypeScript接口定义及接口请求代码，然后自动提交代码并发起MR（Merge Repuest，合并请求），这是不是方便了很多？至于其他诸如多环境管理、流量控制、健康度检查、度量统计等更丰富的工程能力，只需要在实践中不断迭代就可以了。