API 治理这个话题近些年听到的频次越来越多，这实质上是个 web 畛域的倒退无关，也和开发合作形式无关 – 前后端拆散代替了全栈工程师 hold all 的场面，强调的更多的是 API 复用、分工和合作细化。
API 治理的重要性显而易见，每家公司随着业务的倒退，多多少少都会波及到；从开源社区的产品到国内各类商业化产品，能够看到大家对于 API 治理是越来越器重的。
为什么须要治理 API
Little story
联合本身的开发经验，咱们先探讨下，为什么须要治理 API
- 1、在实习的时候是在一家小的游戏公司，人不多，一个产品；过后技术经理的安顿是一个后端 + 一个前端的组合开发，大家都在一个办公室，接口 API 交付依赖的是“讲一声”；这种模式缩小了接口定义、审核以及一些文档的编写，面向指定接口的一对一交付；其实这个过程很顺利，还能够造就共事之间的关系；直到有一天，我对接的前端共事到职了，来了一个新的搭档，而后咱们也刚好要产品升级；每当我改一个接口，前端同学或者测试同学就说，接口不行了。起初我也走了，换了新的后端，“口口相传”API 就断代了。
- 2、第二个 case 是做一个 web 我的项目(利用元数据管理)，前后端拆散的；咱们是先定义有哪些接口，而后再定义参数、返回后果以及这个字段的含意；是面向文档交付的；每个接口开发完之后公布到测试环境，而后他去编写前端接口调用测试；这种耦合度十分高，前端的节奏受制于后端的节奏。
- 3、后面两种面向的都是一个端，再到起初，开始做根底平台，面向的有 web、app（安卓、IOS），各种三方，咱们应用了开源社区的 Yapi 做了私有化部署，可能根本满足日常的需要（也比拟苦楚，前面会提到）。
API 治理带来的益处
从前一节的 case 来看，API 治理的过程是在逐步完善的，从以工程师视角治理到更规范化的基于管理工具的治理；“口口相传”会随着工程师的更替而逐步失去管控，直到无奈追溯；基于文档的治理，从理论状况来看，两次变更之后就会缓缓的弱化文档的位置（改一次接口，就得改一次文档），取而代之的还是工程师主导；还有一点是，不论是基于“口头协定”还是文档，接口在没有交付之前是不具备可测试性的，而且面向的主体繁多，一旦应用端的数量多了，资源扩散和协调的人力老本将指数级增长。
API 治理不仅仅是进步技术能力，而是帮忙推动业务更上一层楼，好的 API 治理能够带给咱们的收益是十分大的。
- 【麻利开发和疾速业务撑持】：帮助咱们可能疾速的创立、共享、监控和调整 API，不须要额定的协同沟通老本而导致生产力降落。
- 【工作流程自动化】：能够从 coding 到 CI 再到 API 管理工作实现自动化同步，绕过繁琐的 API 设计、审核、测试沟通等等；与现有的基础设施绑定起来，提高效率。
- 【保护数据完整性和安全性】：不会随着人员变动而导致 API 数据失落，API 的变更能够通过治理平台的 log 逐个追溯。
咱们当初是怎么做的，有哪些问题
对于 API 治理这块，咱们当初还有专门的 API 技术工作组来负责兼顾所有服务的 API 相干事项，包含设计规范、自动化工具套件建设、API 治理建设等等。然而因为多语言栈、历史接口文档零散、开源工具进行保护等起因，导致相干工作推动起来十分麻烦。
- 历史接口文档有的在 confluence，有的在飞书，有的在 yapi，保护不同工具之间数据一致性十分艰难、低效。
- 随着应用的深刻，开源产品性能上的一些 bug 会被放大（须要进行二次开发，修复版本问题、权限问题等等），而且开源产品的继续维护性没有保障，在对立工具上很难达成对立。
- 对于须要编排的接口，解决起来很麻烦，须要额定的领导文档，step by step，又会导致数据一致性问题产生（领导文档和接口在不同中央治理）
这些问题也迫使咱们在一直寻求各种解决方案，也包含各种商业 API 管理工具的调研，以便于可能给我带来新的解题思路；国内目前企业级的次要 Apifox、ShowDoc、，国外有 boomi、apigee 等（国外的相较于国内的产品要贵不少）；上面次要从性能上比照以后应用 Yapi 和 在调研 Apifox（公网 SaaS 版收费）。
Apifox & Yapi
上面次要是从性能上来看，从继续保护方面来说，Yapi 是社区驱动，没有多少利益牵扯，从 github 上看曾经有很久没有新的提交了，issue 也不足跟进（情怀很重要，然而吃饭更重要，保护一个产品真的很难，是须要给 Yapi 开发小伙伴点赞的）；Apifox 是商业产品，在继续保护和技术支持上不必怎么放心。
疾速部署
工具调研除了性能之外，最外围的是易上手性；从咱们保护部署的 Yapi 来看，环境配置这块是有些简单的，这一点网上也有雷同的痛点
单部署和环境配置来说，Yapi 有很多文章介绍，阐明官网文档自身对于不同环境的适配性有点欠缺，毕竟收费。
Api fox 动手极简，这个是有点出其不意的，不论是客户端版本和 Web 端，创立账户之后即可应用（托管 SaaS，屏蔽了这些环境和配置上的差别）。
功能区散布
- YAPI
- Apifox
论断：总体来说 SaaS 版本的 Apifox 相比于 Yapi 来说，性能面板更加丰盛些；包含了我的项目统计，在线分享，代码生成等。操作上来说，Yapi 须要从分类 -> 我的项目 -> 接口，个人感觉外部的性能 tab 没有 apifox 的正当。
接口详情
- Yapi
- Apifox
论断：接口信息整体差别不大，性能上多了云端 Mock 和疾速申请，Apifox 直观感触更加丰盛和聚焦。
Mock 能力
- Yapi
- Apifox
论断：区别不大，然而 Apifox 有独立的数据模型治理 ( 可复用的数据结构，定义接口返回数据结构及申请参数数据结构（仅 JSON 和 XML 模式）时可间接援用。反对模型间接嵌套援用，间接 JSON/XML 智能导入，反对 oneOf、allOf 等高级组合模式)，Yapi 没有。
数据导入导出
- Yapi
- Apifox
论断：apifox 在反对的导入源上更丰盛，能够满足企业的不同诉求。（Yapi 如同不反对 Swagger 1）
Special
1、数据库操作
反对读取数据库数据，作为接口申请参数应用。反对读取数据库数据，用来校验 (断言) 接口申请是否胜利。
这个其实挺有意思的，在很多状况下，咱们的测试其实须要依赖具体的数据库能力模拟出更贴合理论场景的用例；测试用例上，大多都是基于 H2 这种内存数据库，而依赖 mock 和理论场景又会有一些差别；尤其对于多云环境部署的，不同的云提供的 DB 服务还有一些非凡（比方应用的数据库不同，有的是 Mysql，有的是 Oracle），代码层面的适配无奈通过 mock 来体现，那 Apifox 这个就十分赞了。
2、自动化测试
提供接口汇合测试，能够通过抉择接口（或接口用例）疾速创立测试集。这一点在前文的介绍中有说过，这个是咱们以后的痛点之一，就是组合接口的自动化测试。
更骚的是还能给出残缺的测试报告（反对导出），再也不必放心前端同学说“你不行了”。
3、生成在线接口文档
咱们以后对外部单干的三方是不敌对的，因为业务迭代速度和一些定制化的需要，开放平台能提供的接口 API 十分无限。大多数状况下，咱们都是通过文档将接口的调用逻辑、参数及返回后果语义发送给内部用户（出于平安管控，内部没法间接拜访咱们的 API 平台，API 接口截图也会留痕）。
Apifox 我的项目可“在线分享”API 文档，分享进来的 API 文档可设置为公开或须要明码拜访，十分不便与内部团队合作，实现合作之后也不必放心合作方会把接口扩散进来（变更明码或者敞开受权）。
能够感触下：https://www.apifox.cn/apidoc/s/ce387612-cfdb-478a-b604-b96d1dbc511b/http/5041285
1-3 所提供的能力的确是戳中了咱们的痛点，这可能也是绝大多数公司所共有的问题，Apifox 这几点在产品上的设计集体感觉还是十分优良的。
总结
本文次要联合本身的一些经验以及当前工作中所遇到的问题，对正在应用的开源产品 Yapi 和在调研的 Apifox 做了一些比照和介绍；整体来看 Apifox SaaS (免费版) 相较于 Yapi 来说，还是有不少劣势的。
如果是集体开发者，小团队，或者研发估算无限的公司来说（没有任何性能限度，没有团队应用人数限度，也没有我的项目和接口数量限度），白嫖即可；对于惯例窃密级别的我的项目，SaaS 版本其实曾经够用了。如果对于平安和窃密要求较高，能够思考私有化部署。对于 Apifox 更多能够见其官网 www.apifox.cn