背景:
随着web技术的发展,前后端分离成为越来越多互联网公司构建应用的方式。前后端分离的优势是一套Api可被多个客户端复用,分工和协作被细化,大大提高了编码效率,但同时也带来一些“副作用”:
- 接口文档不可靠。很多小伙伴管理接口文档,有使用wiki的,有word文档的,甚至还有用聊天软件口口相传的,后端接口对于前端就像一个黑盒子,经常遇到问题是接口因未知原因增加参数了,参数名变了,参数被删除了。
- 测试数据生成方案没有统一出口。我们都有这样的经历,前端开发功能依赖后端,解决方案有自己在代码注入json的,还有后端工程师临时搭建一套测试数据服务器,这种情况下势必会影响工作效率和代码质量,也不能及时进行更新。
- 资源分散,无法共享。接口调试每个开发者单独维护一套Postman接口集,每个人无法共用其他人的接口集,存在大量重复填写请求参数工作,最重要的是postman没法跟接口定义关联起来,导致后端没有动力去维护接口文档。
基于此,我们在前端和后端之间搭建了专属桥梁——YApi接口管理平台
介绍:
YApi 是去哪儿移动架构组推出的高效,易用的接口管理平台,旨在为开发人员提供统一的接口管理,Mock服务,帮助开发者轻松维护 、测试API。
特性:
- 基于 Json5 和 Mockjs 定义接口返回数据的结构和文档,效率提升多倍
- 扁平化权限设计,即保证了大型企业级项目的管理,又保证了易用性
- 不仅有类似postman的接口调试,还有强大的测试集功能
- 支持导入 postman , har, swagger 接口数据
- 免费开源,内网部署,信息再也不怕泄露了!
github: https://github.com/YMFE/yapi 在线demo: yapi.demo.qunar.com QQ交流群: 644642474
不错的东东,mock提了这么多年,在项目里这样用算是非常不错的实践,在node社区目前已知的超过4个集成度较高的mock server,加油
很棒,有机会试试
来自酷炫的 CNodeMD
加油 自豪地采用 CNodeJS ionic
前排mark ~
感谢狼叔,感谢大家的支持! YApi马上要开放插件功能,可以根据实际业务需求定制相关功能,敬请期待!
可以导入swagger文档吗?
@178220709 可以
@178220709 不仅支持 swagger,还支持 postman, chrome har数据
顶一个
感觉跟easy-mock差不多。。。
@yuu2lee4 差别很大,easy-mock 只是提供给前端用的 mock平台 ,yapi是建立在连接前后端,qa基础上开发的。
还有YApi 最强大的功能在于插件机制,很多业务上特殊的需求可以基于插件机制定制化,下周一开放插件功能
集合测试这里如果有个切换环境变量的下拉选项就更好用了!【需要批量切换】
支持
@junobatao 需求已收集
@suxiaoxin 支持markdown形式的接口文档的导入么
@yuu2lee4 这种特殊的需求你可以自己开发个插件导入,或者基于chrome(请求录制)成har文件,再导入进来
@suxiaoxin markdown文档现在也算主流吧。。。可以内置支持
@yuu2lee4 不好支持吧,markdown没有固定格式,想怎么写就怎么写,不好转换
赞
貌似导入swagger文档有bug,如果请求没有param,则直接报错了
感谢反馈,马上修复
@178220709 已经修复了,今晚发布的 v1.1.1版本请更新
@all yapi v1.1.1 版本发布,开放了插件功能 https://yapi.ymfe.org/
@178220709 可以尝试下导入 swagger 数据功能,Json-schema 自动转换成 mockJson
@suxiaoxin 其实有点没明白你们的定位,就目前你们说的功能,swagger都有啊,你们说的三大痛点,正好是swagger擅长的, mock,同样可以在前端入口或后端出口,基于swagger api doc 用aop的方式统一提供,还更加一体化。
而且swagger是基于真实接口,可以联动调试,有更准确的反馈。
@178220709 Swagger 的问题在于基于 json-schema,维护起来成本很高,一个几十个字段的json如果基于json-schema,可能变成上百个字段的维护,本来几分钟就能搞定的事情使用swagger可能需要花费好长时间。
还有swagger毕竟只是一个接口文档工具,不能够统一后端接口调试和前端Mock的出口,而 yapi 集成了前端mock 和后端接口运行调试,假如接口定义参数发生改动,可以第一时间通知给前端,前端在调用mock接口也能实时同步到最新的数据。
YApi 最终的使命就是要连接前端,后端,qa,虽然现在貌似在后端和qa方面提供的功能比较弱,但未来会越来越强大。
@suxiaoxin 哪有人真的手工去维护swagger的json文档啊,不都是通过代码反射出来的么。 我说下我们基于swagger规范的一系列工作吧,还请你分析下我们有哪些可以提高的部分。 我们用的是swagger的springMVC集成版本,只要引入依赖,加个路径即可,也内置了可视化页面。 概要设计及评审,我们会定义好业务dto,vo,写rest接口,写接口注释,我们做评审的时候基于这个,讨论接口是否满足业务需求,这个过程中,会反复修改vo 接口签名。 进入开发阶段后,有的项目我们会用aop方式集中mock数据,也有的直接返回empty modal(视前端资源而定) 开发阶段中,前端可以供过url直接拿到我们的实时swagger json doc,我们还有一份基于ts和axios的代码生成模板,通过这个实时api doc,即可实时生成前端接口的promise样板代码。
在这一系列流程中,我们的手工活只有最初用代码描述业务,然后基于此生成swagger,基于swagger评审和迭代,基于swagger提供给前端接口说明和样板代码,这些后续环节都是自动化的。
@178220709 666,你们这个解决方案确实挺好的,yapi未来的功能开发会参考这些比较好的设计。方便的话加下我的微信可以共同探讨下: su335444189