关于api:满足你对-Api-的所有幻想

一、Api 治理的难点在哪？

置信无论是前端，还是后端的测试和开发人员，都遇到过这样的艰难。不同工具之间数据一致性十分艰难、低效。多个零碎之间数据不统一，导致合作低效、频繁出问题，开发测试人员痛苦不堪。

1. 开发人员在 Swagger 定义好文档后，接口调试的时候还须要去 Postman 再定义一遍。
2. 前端开发 Mock 数据的时候又要去 mockjs 定义一遍，还须要手动设置 Mock 规定。
3. 测试人员须要去 JMeter 再定义一遍。
4. 前端依据 mockjs Mock 进去的数据开发完，后端依据 Swagger 定义的接口文档开发完，各自都试测试通过了，本认为能够马上上线，后果一对接发现各种问题：
5. 开发过程中接口变更了，只批改了 Swagger，然而没有及时同步批改 mockjs。
6. 后端开发的接口数据类型和文档不统一，肉眼难以发现问题。
7. 同样，测试在 JMeter 写好的测试用例，真正运行的时候也会发现各种不统一。
8. 工夫久了，各种不统一会越来越重大。

二、Apifox 是什么？

Apifox 是 API 文档、API 调试、API Mock、API 自动化测试一体化合作平台，定位 Postman + Swagger + Mock + JMeter。

通过一套零碎、一份数据，解决多个零碎之间的数据同步问题。只有定义好 API 文档，API 调试、API 数据 Mock、API 自动化测试就能够间接应用，无需再次定义；API 文档和 API 开发调试应用同一个工具，API 调试实现后即可保障和 API 文档定义完全一致。高效、及时、精确！

地址：www.apifox.cn

接下来，我将从以下几个方面逐个演示介绍：

1. API 文档设计
2. API 调试
3. API 自动化测试
4. API 数据 Mock
5. CI 继续集成
6. 数据库操作
7. 主动生成代码
8. 反对 HTTP、TCP、RPC
9. 数据导入 / 导出
10. 团队合作

三、接口设计 (接口文档)

⌨️ 3.1 接口文档

接口设计即定义接口文档标准（如接口门路、参数、返回值、数据结构等）。

• 和 Postman 不一样，[Apifox] 是辨别接口设计和接口运行两个概念的。
• 接口设计：即 新建接口 界面或接口详情里的 编辑 界面，用处是 定义接口文档标准，而不是 运行 接口，所以该界面是只能定义接口根本信息、参数名及参数阐明等，而不能设置参数值。参数值、前置脚本 / 后置脚本 等信息请在接口运行界面或接口用例界面填写。
• 接口运行：即接口详情里的 运行 界面，用处是 长期调试接口，运行 完后，须要点击保留为用例，能力将填写的 参数值、前置脚本 / 后置脚本 等信息保留下来；否则敞开 tab 后，这些信息将会失落。

💻 3.2 疾速上手

1. 点击左侧搜寻框旁边的 + 号按钮即可关上新建窗口，也可应用 快捷键 Ctrl(⌘) + N。

2. 在关上的窗口中，间接定义接口相干信息。

🖨 3.3 接口门路

以斜杠 / 起始的接口 path 局部，如 /pets、/pets/{id}。

1. 接口门路 倡议不要蕴含 HTTP 协定及域名，这部分倡议在 环境治理 的前置 URL 里设置，接口调试时的 URL 会主动加上以后环境的前置 URL。
2. 非凡状况需在接口门路要带上 HTTP 协定及域名的，零碎也能反对，但不倡议这么做。接口调试时，零碎如检测到接口门路是以 http:// 或 https:// 起始的，会主动疏忽以后环境里前置 URL。
3. Apifox 中的 Path 参数是以大括号包裹起来示意，而非冒号起始示意。正确示例：/pets/{id}，谬误示例 /pets/:id。
4. 接口门路 不可蕴含 Query 参数（即 URL 中 ? 后的参数），Query 参数在下方申请参数局部填写。

💽 四、团队治理

成员权限分成两个局部：团队权限和成员权限。团队权限指成员对团队操作的权限，我的项目权限指成员对我的项目操作的权限。

📽 4.1 权限治理

团队角色分 所有者、管理者 和普通用户，对应权限如下：

⏱ 4.2 我的项目权限

为了满足团队的多层次治理需要，每个成员能够按我的项目设置管理员、一般成员、只读成员、禁止拜访的角色，对应权限如下：

📞 4.3 应用阐明

当须要批改权限或查看成员权限时，能够点击左上角的 项目名称，进入团队页面。在对应的我的项目下点击 成员 / 权限 tab，点击对应成员的 设置，就能够看到该成员在该我的项目内的团队权限和我的项目权限，并依据须要进行批改。

☎️ 五、团队合作流程

1. 前端 （或 后端）在 [Apifox] 上定好接口文档初稿。
2. 前后端 一起评审、欠缺接口文档，定好接口用例。
3. 前端 应用零碎依据接口文档主动生成的 Mock 数据进入开发，无需手写 mock 规定。
4. 后端 应用接口用例 调试开发中接口，只有所有接口用例调试通过，接口就开发实现了。如开发过程中接口有变动，调试的时候就自动更新了文档，零老本的保障了接口保护的及时性。
5. 后端 每次调试完一个性能就保留为一个接口用例。
6. 测试人员 间接应用接口用例测试接口。
7. 所有接口开发实现后，测试人员 （也能够是 后端）应用汇合测试性能进行多接口集成测试，残缺测试整个接口调用流程。
8. 前后端 都开发完，前端从 Mock 数据切换到正式数据，联调通常都会十分顺利，因为前后端单方都齐全恪守了接口定义的标准。

📠 六、导入数据

🎙 6.1 性能阐明

反对导入 OpenApi (原 Swagger)、Postman、HAR、RAML、RAP2、JMeter、YApi、Eolinker、NEI、DOClever、ApiPost、Apizza、DOCWAY、ShowDoc、apiDoc、I/O Docs、WADL、Google Discovery 等数据格式，不便旧我的项目迁徙。

⏰ 6.2 手动导入

关上 我的项目设置 面板，点击 手动导入，可抉择文件导入或 URL 导入。

以导入 Apifox 格局为例，导入可选内容包含：接口、数据模型、环境、测试用例、测试套件

📡 七、导出数据

💎 7.1 性能阐明

1. 反对间接导出 OpenAPI (原 Swagger)、HTML、Markdown、Apifox 等数据格式。
2. OpenAPI (Swagger) 反对导出 3.1、3.0、2.0 版本。
3. OpenAPI (Swagger) 反对导出离线文件，或间接关上 URL。

💵 7.1 导出 PDF、Word 办法

目前还不反对间接导出 PDF、Word 等其余格局数据，但可应用内部工具将 Markdown 转为对应格局。

如应用 [Typora] 即可将 Markdown 导出为 PDF、Word、OpenOffice、Epub 等格局。

📺 八、Mock 语法

Apifox Mock 语法齐全兼容 Mock.js（数据占位符形式），并扩大了一些 Mock.js 没有的语法（如国内手机号 @phone）。

• 如现有 Mock 语法无奈满足需要，倡议应用 正则表达式 @regexp 来实现灵便的定制。正则表达式根本能满足各种非凡场景的需要。

🔋 8.1 根本写法

主动转换 是应用 javascript 语言默认数据转换方法进行转换。

🔌 8.2 正则表达式

留神:

• Apifox 版本号大于等于 1.0.12 才反对正则表达式。
• regexp 参数必须以 / 起始和结尾。

📟 九、脚本

[Apifox] 蕴含一个基于 Javascript 的脚本引擎，通过脚本（JavaScript 代码片段）可实现在接口申请或汇合测试时增加动静行为。

📼 9.1 脚本可实现的性能

1. 测试（断言）申请返回后果的正确性（后置脚本）。
2. 动静批改接口申请参数，如减少接口签名参数等（前置脚本）。
3. 接口申请之间传递数据（应用脚本操作变量）。
4. 脚本能够间接 调用其余语言编写的程序，反对 java(.jar)、python、php、js、BeanShell、go、shell、ruby、Lua 等语言编写的内部程序。
5. 其余。

☎️ 9.2 应用形式

以下两个环节可增加脚本：

1. 在将申请发送到服务器之前，应用 前置脚本。
2. 收到响应后，应用 后置脚本(断言测试)。

🔨 9.3 全局脚本和分组脚本

1. 反对全局设置（在我的项目概览里设置）前置操作、后置操作，设置后我的项目里的所有接口运行时都会失效。
2. 反对分组里设置前置操作、后置操作，设置后分组里的所有接口运行时都会失效。

接口申请的执行流程如下：

• [全局前置脚本] -> [分组前置脚本] -> [接口前置脚本] -> [发送接口申请] -> [返回接口后果] -> [全局后置脚本] -> [分组后置脚本] -> [接口后置脚本]

🗑 9.4 调试脚本

调试脚本能够在 前置脚本 和 后置脚本 里编写，应用 console.log(‘hello’)形式将调试信息写入控制台，关上 控制台 即可查看。

🛢 十、快捷键

为了进步你的开发效率，也可应用各种快捷键：

官网下载地址：www.apifox.cn