- Published on
ApiFox上手简介
- Authors
- Name
- McDaddy(戣蓦)
安装与更新
建议安装桌面版 官网地址, 因为网页版目前是beta的状态,经过个人测试也是有些小bug的
更新版本需要在设置中选择软件版本 -> 检查更新
快速开始
进入项目
选择当前团队,同时将自己的昵称改为中文名方便辨认
新建接口
编辑基本信息
- url
- method
- 名称
- 分组
- 责任人
- 描述说明
编辑请求结构
- params
- body
- header
编辑返回结构体
- 使用全局统一的返回结构体
- 在具体数据部分选择解除关联,然后填充具体类型
- 可以根据状态码来定义不同的返回体
测试接口
- 在文档或文档编辑界面点击运行
- 填入必须的参数
- 点击发送
这样就可以得到类似postman的测试接口效果
核心功能与解决痛点
数据结构的复用
在编写api文档时,是否经常要写相同的结构体,为此反复复制粘贴。初次建稿问题不大,但如果后期做统一修改就很困难。
假设下面是所有api的公共返回体的初稿,此结构体会在文档上出现N次,某天需要统一增加一个字段,就需要在文档上修改N处
{
code: 0,
message: 'Ok',
data: {
items:[
"xxxxx", //模糊搜索结果,人名列表
"xxxxx",
....
]
}
}
又比如高频使用的枚举, 如果某天修改了这个枚举类型,那么就需要全局搜索来修改
{
version: 1.1/1.2/1.3/1.4
}
非GET接口的测试
传统测试方法
- 要求前端部署来测试
- 写一个巨复杂的curl来测试
- 利用postman这类工具来测试
即使是使用postman这样的工具来测试,仍然会有以下问题
- 无法提示哪些参数需要被发送
- 无法校验入参和出参是否合规
- 手动输入参数太繁琐
apifox可以生成合规的mock数据作为测试数据,做到一键测试
字段合规
我们在做form表单这类需求时,时刻要注意的就是各类表单校验条件,具体例如
- 类型限制
- 字段长度限制
- 字段枚举限制
- 非空限制
- 数值范围限制
- 正则限制
- 唯一性限制
- 元素个数限制
- 。。。。。。
而这些东西不应该只存在于PRD或者数据库表设计之中,因为前端是不会去看db里面一个字段被设计了多少长度,用的是什么类型
这些内容其实都是可以体现在api的配置中的,在字段配置行点击更多
本地mock
对前端同学来说是脱离后端独立开发的神器
传统开发接口
- 等待后端发布,美其名曰需要真实数据来调试
- 自己写mock(mock文件、临时代码、mock server),但效率低,mock价值低
- 利用云端平台,但平台的mock大多不够智能和全面
- 不能指定单个字段的规则
- 不能针对具体入参给出特定的返回
apifox的mock策略
- 支持本地和云端mock,即使没有网络也能开发接口
- 自带全面的字段mock类型,即使没有学习过mockjs也能轻松mock
- 支持高级mock
全局参数
如果任何一个请求都需要带上相同的参数或者header,比如jwtToken,全局参数就可以解决这个问题
同时参数还可以把敏感信息保留在本地,不暴露到公网上
文档输出
项目设置 -> 导出数据 -> 选择格式 -> 下载
这样就能得到一个排版优良,信息完备的API文档
接口自动化测试
当前不足
- 没有消息通知机制
- 无法显示一段时间修改的前后对比