最近总有前端小伙伴来找我抱怨：

“后端接口出来太晚，影响我的任务进度！”

“后端接口改了也不通知我一下，到冒烟测试的时候报一堆的错！”。

我拉后端小伙伴了解情况，结果问题没解决，抱怨倒是又收集了一批：

“我先提供出来的接口他们不用，非得要我排后面的那个接口。”

“接口加参数的时候，我在群里@了，是他们自己不看。”

“每次修改了接口，还要赶紧去 wiki 上面同步修改一下，太麻烦了。偶尔忘记修改了就会被项目上同事投诉。”

好吧，大家都难，如果再加入管理手段来解决协同的问题，估计只会加重大家的负担，以理服人的打算就此打消吧。但是事情还得解决，开发和产品经理的关系已经剑拔弩张了，前端和后端要是再冲突起来。。。打住，不能再往下想象了。

了解到 Eolink 能很好的解决前后台开发中的 API 协调问题，我决定去试用一下这个平台。

当然，作为一个工作了十几年的老码农，是不会做没有准备的试用的。先列出问题：

1. 在代码工程中通过 Swagger 写好的接口，能不能支持一键导入？
2. 代码工程中的 Swagger 接口的定义信息有变更，能不能很便利的同步？
3. 接口有变更，能不能及时的通知到前端开发？
4. 接口定义信息能不能导出成 pdf 文档，便于发给第三方？
5. 接口能直接给前端调用？能不能自动生成 mock 数据（特别是造测试分页的数据也挺累的）？
6. 能不能直接像 jmeter 一样直接测试我的服务端真实的接口？
7. 要不要收费？

问题准备就绪，正式一探究竟

SaaS 平台的首页看起来还挺清爽。。等等，右上角的头像怎么是个妹子？注册的时候可没让我选性别啊，我一大老爷们看到自己的头像是个妹子，好尴尬的，你好歹搞个中性一点的。

右下角有个【了解 API 研发管理】，点进去了解一下平台的设计理念先。

从左侧菜单来看，API 管理、API  测试、测试用例管理、数据 mock 都有。对 API 管理的发展过程、痛点及解决方案的介绍也挺中肯。更细的内容咱就不研究了，是骡子是马，还是得看功能好不好用。

API管理

Eolink 平台的 API 是以项目来进行管理的，先创建一个项目。刚刚创建完项目，又弹出操作指引，不是登录进来时已经登过一次了么？虽然直接叉掉就好了，但是我这时对平台抱的希望挺大，这种体验瑕疵还是有点打击我对平台的信心。

导入 Swagger 接口

点击“+API”按钮，在下拉选项中选择“导入 API”

支持的导入类型还挺全，我主要关注 Swagger 接口的导入，发现我还得把本地项目中的接口生成一份 json 文件。发现做开发这么久，还真没关注过 swagger 接口还可以导出成 json 文件，不过有万能的 google，这难不倒我。。此处省略一万字。。（SaaS 版本不能直接通过本地的 swagger 接口访问地址导入接口，可以理解，但是期待本地安装的 Eolink 应用，可以支持通过 server 地址一键导入，真的会方便很多）

准备好 json 文件后，开始执行导入

这里的 API 状态挺好，可以清晰的标识 API 所处的开发阶段。

版本号这个我好像暂时用不上，我们的接口如果要区分版本的话，会在请求路径上做区分。估计也有的项目是在请求 header 中添加版本参数来区分接口版本号，但这种做法感觉不太友好。这里的版本具体会起啥作用，还有待后续考察。

点击【确定】后，就生成了一个 API。

导入接口还算简单，下一步把前端开发添加进来，后端就可以愉快的去编码了。

突然发现 API 列表的 tab 边上还有个“+”，点一下竟然触发了新技能

点击“+”后会出来一个新 tab 页：

看到【发送[通过服务器]】时，我有点小失望，我的服务只能局域网访问，通过服务器访问肯定访问不到了，不过也能理解，毕竟 SaaS 平台，有这个限制也正常。不过看到这个按钮右边有一个下拉提示，点击一下，出来个【切换使用浏览器测试】的菜单，如果通过浏览器那是可以访问到我本地接口的，这个牛逼啊！

而且右边还有一个【保存为新 API】，那我就可以把本地 swagger 接口配上来，测试通过后，直接保存为新 API。不管是第一次新增接口的时候，还是本地开发完一版之后做接口更新，都可以和自测的动作结合在一起了。

突然有种豁然开朗的感觉。不过，这个浏览器测试的模式是不是和我预想的一样呢？这个问题就留待我们下次再来验证吧。