Published on

ApiFox上手简介

Authors
  • avatar
    Name
    McDaddy(戣蓦)
    Twitter

安装与更新

建议安装桌面版 官网地址, 因为网页版目前是beta的状态,经过个人测试也是有些小bug的

更新版本需要在设置中选择软件版本 -> 检查更新

image-20220915105446313

快速开始

进入项目

选择当前团队,同时将自己的昵称改为中文名方便辨认

image-20220915105944775image-20220915110124369

新建接口

编辑基本信息

  • 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接口的测试

传统测试方法

  1. 要求前端部署来测试
  2. 写一个巨复杂的curl来测试
  3. 利用postman这类工具来测试

即使是使用postman这样的工具来测试,仍然会有以下问题

  1. 无法提示哪些参数需要被发送
  2. 无法校验入参和出参是否合规
  3. 手动输入参数太繁琐

apifox可以生成合规的mock数据作为测试数据,做到一键测试

字段合规

我们在做form表单这类需求时,时刻要注意的就是各类表单校验条件,具体例如

  • 类型限制
  • 字段长度限制
  • 字段枚举限制
  • 非空限制
  • 数值范围限制
  • 正则限制
  • 唯一性限制
  • 元素个数限制
  • 。。。。。。

而这些东西不应该只存在于PRD或者数据库表设计之中,因为前端是不会去看db里面一个字段被设计了多少长度,用的是什么类型

这些内容其实都是可以体现在api的配置中的,在字段配置行点击更多

image-20220915121413817

本地mock

对前端同学来说是脱离后端独立开发的神器

传统开发接口

  • 等待后端发布,美其名曰需要真实数据来调试
  • 自己写mock(mock文件、临时代码、mock server),但效率低,mock价值低
  • 利用云端平台,但平台的mock大多不够智能和全面
    • 不能指定单个字段的规则
    • 不能针对具体入参给出特定的返回

apifox的mock策略

  • 支持本地和云端mock,即使没有网络也能开发接口
  • 自带全面的字段mock类型,即使没有学习过mockjs也能轻松mock
  • 支持高级mock

全局参数

如果任何一个请求都需要带上相同的参数或者header,比如jwtToken,全局参数就可以解决这个问题

同时参数还可以把敏感信息保留在本地,不暴露到公网上

image-20220915134243652

文档输出

项目设置 -> 导出数据 -> 选择格式 -> 下载

这样就能得到一个排版优良,信息完备的API文档

接口自动化测试

当前不足

  • 没有消息通知机制
  • 无法显示一段时间修改的前后对比