Postman那么好用，为啥还要开发API管理平台？

Postman作为一款优秀的接口测试工具，可以说是研发和测试人员在接口调试和接口自测过程中人手必备工具。

Postman解决的问题

在我们API研发过程中，使用Postman可以很方便的进行接口自测和接口测试功能，还可以定义环境变量、断言等等。

但是这都是单兵作战，各测各的。比如：研发人员自测时创建的API，测试人员无法直接使用。其实，在整个API研发流程中是一个团队协作的过程。

可能有人说Postman付费版可以解决团队协作的问题，但是估计大多数人使用的都是免费版或者单机版的，所以本文说Postman时是代指免费版本的Postman。有使用Postman付费版的可以后台留言，看看人数多不多？

API研发中遇到的问题

1. 团队协作：

   各成员之间独立工作，重复创建API接口的工作，而且有成员工作变动或者离职，可能之前写的接口用例就没了。

2. 接口定义不规范：

   在方案设计时，只定义一个request json就作为接口协议，导致在研发过程中有很多细节需要不断沟通确认。

3. 接口变动不同步：

   研发接口修改时，未及时同步前端和测试人员，导致实现的功能不一致。

4. 接口联调耗时长：

   前后端根据各自理解的接口协议进行独立开发，自测都说没问题，联调的时候发现很多逻辑走不通，耗时费力。

API管理平台如何解决

下面说一说使用API管理平台，如何解决这些问题，在这里我以开源的API管理平台YApi为例，也方便大家直接拿来实践。

YApi是一款优秀的开源API管理平台，至少是我认为的最优秀的API管理平台，没有之一。目前在GitHub上已有2w+的Star数。可能已经有很多公司在使用了，欢迎后台留言交流。

1. 团队管理：可以通过分组和项目来对API进行管理，通过不同的角色来控制人员的API访问权限。在组织架构调整时，也可以很方便的进行项目迁移。

2. 接口协议：重点来说下这个接口协议，因为接口协议是API研发过程中的基础，也是以后功能扩展的基石。

   可能很多人觉得定义一个Request Json就叫接口协议了，甚至有些研发觉得我开发完服务通过Swagger导出就有接口协议了。

   可以看下在YApi中，接口定义需要的信息：

   

   需要定义名称、类型、是否必须、默认值、备注这些还比较容易理解。在其他信息里面还会包含mock规则，或者取值范围。

   

   这个的用处是，在你接口请求时，YApi可以根据你的规则自动生成随机数据，方便接口调用。

   另一个就是有点测试前移的味道，就是在定义接口的时候就确定好字段的取值范围，这其实也是在研发中需要考虑的问题，直接在接口协议上定义好，也省得开发中考虑不全的问题。

3. 接口调试：

   YApi会根据接口定义自动生成接口参数，方便后端开发进行接口调试。同时也会生成MockServer，前端可以直接调用此服务进行接口调用。这样前端和后端都面向同一份接口协议进行研发，而且，接口协议的改动除了会邮件通知团队成员外，还会立即在接口调用中立即体现出来，前后端研发都能第一时间感知到变动。

YApi还有更多的自动化测试，服务端测试，数据统计等功能，感兴趣的同学可以去体验下，也可以后台交流。

API管理平台的意义

1. 资产化：可以使团队成员的劳动成果沉淀下来，后续人员可以在此基础上继续迭代，不会因为人员的流动导致之前投入的工作没得了。

2. 文档驱动开发：重塑研发流程，以接口文档来驱动研发，接口修改先改文档再改代码。沟通是团队最大的成本，以文档为准是最简单有效的方式。

3. 团队协作：团队全部面向同一平台工作，统一制定接口协议，使用协议进行接口调试，Mock和测试用例。

API管理平台带来的问题

最大的问题就是管理的问题，可能很多人没有意识到，或者没有管理的能力。当我们引入平台时，要做的第一件事就是管理。比如：人员的管理，权限的管理，接口的分组和管理。首先需要管理好接口，才会有好用的结果。就好比想借书你会想到去图书馆，但是前提是有图书管理员把图书管理的井井有条，你才能找到要借的书。如果无人管理，图书满屋子乱堆，你还会觉得图书馆是借书的好地方吗？

总结

Postman只是解决了API研发流程中自测环节的问题，我们开发API管理平台是解决整个API研发周期中的问题。未来还可以扩展接口代码生成、接口用例自动生成等功能。