前后端API沟通方式标准化
由后端提供统一格式的API
描述文档,公司应用比较多的有Swagger
、APIDoc
.建议统一成Swagger Json
.
AMP需要做什么?
- 支持导入类似
Swagger Json
的API
描述文件,并且生成对应的Mock
接口数据 - 支持权限的划分,多人编辑
- 提供
Mock.js
模版数据功能
解决的问题
- 统一前后端沟通标准(
API
描述文档) - 支持自动生成
Mock
数据
争议问题
AMP
平台上的数据是由后端开发人员提供的文件生成,这个时候前端的开发必须依赖后端开发人员提供文档的质量,这样子的话会影响到前端的开发。一旦描述文档生成mock,前端mock是必须要要与平台关联起来。因为mock平台不支持外网访问,如果想在家去做开发将会比较困难。
假设现在文档已经形成,但是后端在开发的时候发现某些
API
设计有些许问题,然后直接在代码修改了,但是忘记更新文档,那么这个时候我的测试环境等CI
就无法完成,并且又可能前端为了找出这个差异需要花一定的时间去DEBUG
。这里咱们就要说说后端开发人员的文档形成模式了,咱们暂且说Swagger
。它提供了两种文档编辑模式:
侵入式
- 优点:代码修改,文档自动变化。解决了上述问题
- 缺点:侵入业务逻辑,上线可以去掉,但是修改一个接口会比较繁琐,增加开发任务
编辑式
- 优点:修改文档迅速
- 缺点:手动维护文档,会出现上述错误
思考的解决方案
针对问题2,我们把
AMP
上的接口当作一个管理平台,然后本地写个脚本或者是工具,把接口生成本地文件,然后DEV
rewrite 到本地文件。同时还可以满足统一个接口的不同开发者差异化,如果AMP
提供了MOCKJS
的功能的话这个优势可以取消。针对问题3,提供一层数据检查机制,当后端完成一个测试环境的接口时自动去跑一边测试接口与描述文档生成的接口的差异化检查。如果有差异自动提醒