@
int64ago 感谢你提出的这些顾虑,也引发了我的思考,希望和大家共同探讨下
-----------------
在做 puer-mock 的时候,我参考了很多接口规范和接口平台,主要是从 Swagger 和 RAP 那里获得的灵感,希望可以尽量简单的通过 JSON 配置来定义一个接口,并生成随机数据,继而形成一个标准的接口文档(谁说接口文档只能是 word 之类的)。
如果形成了接口规范,我想后面的事情都是有可能的。
> 应该有个平台
puer-mock 目前比较适合中小型团队的前后端协作,因为是直接编写 JSON 文件做为接口文档的,因此需要双方都熟悉配置,对于技术团队没什么大问题,定义接口的方式也足够简单,基本上熟悉 HTTP 的,看一眼就明白这些接口的定义了。
如果要更友好些,那就需要做一层 UI ,做一个系统,一个平台,通过可视化的手段来生成接口配置文件就好了。所以说定义好接口规范是最基础最重要的第一步, puer-mock 尝试做好这一步。
> 平台的修改应该很容易反应到本地 Mock 数据
puer-mock 支持修改了接口配置后马上生效,应该还是能够满足大部分需求的
> Mock 生成的数据应该同时对 iOS/Android/... 都友好
puer-mock 生成的 mock 没有针对某个客户端,属于后端接口规范,对客户端都是友好的,也没有任何侵入性
> Mock 数据的定义应该可以自己插入一些简单逻辑
puer-mock 后面是通过强大的 mock.js 来生成 mock 数据,因此针对"某个字段只返回 1-10 之间的数字"这样的需求是完全满足的。
例如配置方式如下
"field1": "@integer(1, 10)"
> Mock 数据的定义应该考虑到可复用性
puer-mock 在参考 Swagger 规范的时候就意识到了这个问题,但出于简单的考虑,暂时只能复制粘贴那些重复的 response 定义,这确实是埋了个坑,但对于中小型团队应该还好啦,有规范总比没有的好。关于这点, puer-mock 考虑以后是否通过 Swagger ref 的方式来引用预先定义好的数据结构,或者通过上层的接口平台来解决这个问题,将数据结构定义在接口平台,让接口平台来生成重复的数据结构引用,来避免手工复制粘贴造成数据结构出现潜在的不一致性问题
> Mock 的管理应该区分用户权限
这个不在 puer-mock 的考虑范围,上层的接口平台可以来做这个事情,这也是为什么越往后统一的接口平台越重要的原因,形成部门级公司级的协作流程
> Mock 接口和数据定义后,应该可以有条件直接生成文档
目前 puer-mock 内置了接口文档,可以在线查看,虽然还比较简陋,只是格式化展示了接口定义的 JSON 文件,做了分组便于查看。但根据接口定义的 JSON 输出接口文档完全是可以自定义的,所以想生成一份高大上的接口文档完全没有问题
-----------------
最后说下目前 puer-mock 已经在我厂中推行,有 3 个项目(小公司项目本来就不多啊,大家见笑了)使用了,定义了 50 多个后端接口,前端 /App 端 /后端都表示很实用,确实提高了工作效率