关于接口文档:接口文档进化图鉴有些古早接口文档工具你可能都没用过

2次阅读

共计 2533 个字符,预计需要花费 7 分钟才能阅读完成。

可能当初的小程序员听到以前还有人用过 word 来做接口文档,会诧异得不行,但在前后端拆散推广的晚期,的确没有那么多趁手好用的接口文档工具。

互联网倒退到当初,接口文档也经验了从简略的 word 到 markdown,到 swagger,到 Apifox 等逐渐进化的形式,变得越来越好看,越来越标准,也反对越来越多的性能辅助调试。

接下来给大家盘点一下这些年接口文档的进化历程。

一、接口文档的幼年体:word

一开始是前后端拆散,后端得告知前端接口的各项信息,不便前端调用。
那须要提供的信息也就那些,就用 word 写吧,于是就有了这样的接口文档:

问题仿佛解决了,但我的项目嘛,是不停批改和迭代的,这样会导致:

这份接口文档是随着我的项目进行频繁改变的。
每更新一次,就须要给我的项目成员散发一次新的接口文档

于是:
A. 每改变一次就要新建一份,复制给项目组里很多人,这样一个文档复制来复制去,项目组里这么多人,谁都不晓得拿到的是不是全新版本;

B. 改一点就要生成一个新文档,于是文件夹里的接口文档可能就是这种模式:

是谁哭了我不说。

这些痛点促成了接口文档的第一次进化:
从 word 版的接口文档进化成网页版的接口文档。

二、接口文档的成长体:Markdown

网页版的接口文档多完满,只须要散发一个链接给我的项目成员保存起来。

这样,如果后端批改了接口,间接在网页里批改,就保障大家看到的都是最新版本的,也不必每次一有改变就发一份新文档给大家。

这样一个由 markdown 生成的动态的 html 页面,一个接口的要害因素全都有

问题解决!

但——
新的问题又产生了。

这个接口文档是能用了,但又没那么好用,比如说:

1. 写接口挺麻烦的,齐全纯手工写,没有任何辅助工具,十分花工夫

2. 接口写完还不能立即看到生成的接口文档的成果,写错了还要从新回去调

3. 没有接口标准束缚,接口文档怎么写,哪些参数要写,哪些不写,出现模式怎么样全凭开发人员自身的业务水准。

于是就开始了新的一轮的进化——有人开发了一个工具,专门就用来写接口文档。

三、接口文档的齐全体:swagger

怎么写?
在 swagger editor 里编写合乎 swagger 语法的接口文档,来生成接口文档,编写完的接口文档能够在 swagger editor 的右侧实时预览:

于是,进化到这个齐全体阶段的接口文档工具曾经实现了如下性能:

1. 网页版接口文档反对的在线查看性能,当然他也有,而且这个接口文档的款式是合乎 open api3.0 标准的,如果写得不合乎语法,swagger editor 还会报错来纠正你。

一个规范的接口所应具备的信息:接口办法、接口门路、申请和响应参数,都能依照固定的格局出现进去。

2. 它还具备了初步、简略的调试性能,就是接口申请参数为空格,填写参数、发送申请,就能返回响应参数

如同曾经够用了对不对?

但——等等,这些如果是开发本人一个人用还行,但如果要使用到我的项目里,那么多的接口文档,蛮难治理的,swagger editor 不提供我的项目层级的归档和治理,保护也麻烦。

而且,到目前为止,也没有逃脱接口文档要靠手写生成的命运,还要去学 swagger 注解,这样一来,学习老本有了,工作效率也进步不下来。

生成的接口文档,前端须要应用接口信息来调试页面,测试会用它来验证接口。
但目前接口文档的性能,对前端和测试的工作反对得还不够呀~

如同 …. 还能够更完满??!

有痛点就会有解决方案,于是接口文档开始了新一轮的进化之路,进入究极进化状态的接口文档工具是——

四、接口文档的究极进化状态:Apifox

想要团队合作?安顿。
想要不必写代码就能生成接口文档?能够。
想要间接在接口文档上调试接口?反对。
接口还没上生产环境、但想要模仿数据能够调试前端页面?反对。
想要间接用接口数据来做自动化测试?安顿。

于是一个究极进化状态的接口文档工具就诞生了。

首先是在曾经存在的接口文档性能上做优化:

A. 可视化的接口设计页面,不必写 swagger 注解,填完参数保留就是一份接口文档。

只有你懂接口的常识就能上手写,四舍五入这学习老本就是零。

B. 一键导出接口文档,反对只分享局部接口文档,设置过期工夫,设置明码

C. 接口文档实时更新
一旦接口文档产生变更,数据会实时同步到参加我的项目的所有成员

其次是给前端和测试疯狂加外挂:

A. 接口文档页面反对在线调试

分享进来的接口文档页面反对简略的根底调试性能,如果你如要更加弱小的调试辅助,则能够应用 Apifox 客户端。

客户端的调试性能对提取变量、断言、连贯数据库等性能都做了可视化封装,不必写脚本,如果 有简单的调试需要,仍旧反对脚本调试性能

B. 反对生成代码
反对的代码品种也蛮多的,包含前后端罕用的各种语言和框架,总共有 130 多种,javascript 和 swift,java 等等生成的前端代码复制就能用。

不仅反对生成接口申请代码,也反对生成数据模型代码,整个我的项目的代码,能够按需生成,而后本人再去做调整,这样须要写的代码量就大大减少了。

F. 提供 mock 环境
在接口未上线时也能模仿接口申请,结构出高度实在的业务数据供前端测试页面,后端、测试进行接口的调试和测试

能够复制链接到浏览器查看生成的在线文档:

https://www.apifox.cn/apidoc/…

最初是将接口的一整条工作链整合到它这一个工具里:

A. 反对我的项目档次的合作

每个接口归属于不同的模块,分属到不同的目录之中。
后端、前端、测试能够应用同一套接口数据源,也就是说接口创立进去之后,后端在下面保护,前端应用他做接口 mock,测试用它做接口自动化,数据变更实时同步到各端,不须要切换多个软件。

B. 反对导入 postman,swagger 等多达 20 多种格局的接口数据,零老本实现我的项目迁徙

C. 反对导出 swagger,html,word 格局的接口文档,也不绑架用户,你想迁徙到其余零碎也大大方方成全你。

这样一套组合拳打下来,基本上你能想到的接口文档该有的性能它都有了。

官网地址:www.apifox.cn

总结

因而,总结下来,接口文档始终以来都在一直地进化,战斗力也越来越强,也给研发人员提供了越来越到位的帮忙,让他们可能少写不必要的代码,少做反复的工作。
大家能够依据本人我的项目的理论状况,选用适合的工具。

正文完
 0