场景说明:
在真实工作环境中,由于后端与前端并行开发,所以在开发前期是没有后端接口可供前端使用的,
所以学会最适合自己的 Mock 数据的方法就很有必要。
本篇文章会对比一些业界常见的 Mock 方案,大家根据自身情况选择并配置其中最适合的方案。
常见 Mock 方案
1. 代码侵入(直接在代码中写死 Mock 数据,或者请求本地的 JSON 文件)
侵入的意思是其实本身书写的相关代码是一些与真实项目或业务无关的代码,后期等真实接口出来之后,这些代码需要删除的,这就是代码侵入了项目。
优点:无
缺点:
① 和其他方案比 Mock 效果不好;
② 与真实的 Server 环境的切换非常麻烦(删除自己写死的一些数据或者 JSON 文件,对接真实接口),一切需要侵入代码并手动切换环境的行为都是不友好的。
2. 请求拦截
代表:Mock.js
示例:
Mock.mock(/\\/api\\/visitor\\/list/, 'get', {
code: 2000,
msg: 'ok',
'data|10': [
{
'id|+1': 6,
'name': '@csentence(5)',
'tag': '@integer(6, 9)-@integer(10,14)岁 @cword("零有", 1)基础',
'lesson_image': "<https://images/pexels.com/3737094/pexels-photo-3737094.jpeg",
'lesson_package': 'L1基础指令课',
'done': '@integer(10000, 99999)',
}
]
})
优点:
①. 与前端代码分离
②. 可生成随机数据
缺点:
①. 数据都是动态生成的假数据,无法真实模拟增删改查的情况
②. 只支持 ajax,不支持 fetch(想要了解 ajax 和 fetch 区别的同学可以点这里)
对于上述 fetch 解析进行的一点补充:
这里我们通过网络获取一个 JSON 文件并将其打印到控制台。最简单的用法是只提供一个参数用来指明想
fetch()
到的资源路径,然后返回一个包含响应结果的 promise(一个 Response 对象)。当然它只是一个 HTTP 响应,而不是真的 JSON。为了获取JSON的内容,我们需要使用 json() 方法(该方法返回一个将响应 body 解析成 JSON 的 promise)。
3. 接口管理工具
优点:
①. 配置功能强大,接口管理与 Mock 一体,后端修改接口 Mock 也跟着更改,可靠。
缺点:
① 配置复杂,依赖后端,可能会出现后端不愿意出手,或者等配置完了,接口也开发出来了的情况。
② 一般会作为大团队的基础建设而存在,没有这个条件的话慎重。
4. 本地 node 服务器
代表:json-server
优点:
① 配置简单,json-server 甚至可以 0 代码 30 秒启动一个 REST API Server
② 自定义程度高,一切尽在掌握中
③ 增删改查真实模拟
缺点:
① 与接口管理工具相比,无法随着后端 API 的修改而自动修改
扩展:
REST API
一句话总结: URI 代表 资源/对象,METHOD 代表行为
GET /tickets // 列表
GET /tickets/12 // 详情
POST /tickets // 增加
PUT /tickets/12 // 替换
PATCH /tickets/ 12 // 修改
DELETE /tickets/12 // 删除
点我了解 PATCH vs PUT
附:该文章属于学习总结,参考老师的文档又给总结了一遍,也添加了一些自己的理解与思考。