通过Swagger系列可以快速生成API文档,但是这种API文档生成是需要在接口上添加注解等,这表明这是一种侵入式方式; 那么有没有非侵入式方式呢, 比如通过注释生成文档? 本文主要介绍非侵入式的方式及集成Smart-doc案例。我们构建知识体系时使用Smart-doc这类工具并不是目标,而是要了解非侵入方式能做到什么程度和技术思路。 @pdai
准备知识点
需要了解Swagger侵入性和依赖性, 以及Smart-Doc这类工具如何解决这些问题, 部分内容来自官方网站。@pdai
为什么会产生Smart-Doc这类工具?
既然有了Swagger, 为何还会产生Smart-Doc这类工具呢? 本质上是Swagger侵入性和依赖性。
我们来看下目前主流的技术文档工具存在什么问题:
- 侵入性强,需要编写大量注解,代表工具如:swagger,还有一些公司自研的文档工具
- 强依赖性,如果项目不想使用该工具,业务代码无法编译通过。
- 代码解析能力弱,使用文档不齐全,主要代表为国内众多开源的相关工具。
- 众多基于注释分析的工具无法解析jar包里面的注释(sources jar包),需要人工配置源码路径,无法满足DevOps构建场景。
- 部分工具无法支持多模块复杂项目代码分析。
什么是Smart-Doc?有哪些特性?
smart-doc是一款同时支持JAVA REST API和Apache Dubbo RPC接口文档生成的工具,smart-doc在业内率先提出基于JAVA泛型定义推导的理念, 完全基于接口源码来分析生成接口文档,不采用任何注解侵入到业务代码中。你只需要按照java-doc标准编写注释, smart-doc就能帮你生成一个简易明了的Markdown、HTML5、Postman Collection2.0+、OpenAPI 3.0+的文档。
- 零注解、零学习成本、只需要写标准JAVA注释。
- 基于源代码接口定义自动推导,强大的返回结构推导。
- 支持Spring MVC、Spring Boot、Spring Boot Web Flux(controller书写方式)、Feign。
- 支持Callable、Future、CompletableFuture等异步接口返回的推导。
- 支持JavaBean上的JSR303参数校验规范,包括分组验证。
- 对JSON请求参数的接口能够自动生成模拟JSON参数。
- 对一些常用字段定义能够生成有效的模拟值。
- 支持生成JSON返回值示例。
- 支持从项目外部加载源代码来生成字段注释(包括标准规范发布的jar包)。
- 支持生成多种格式文档:Markdown、HTML5、Asciidoctor、Postman Collection、OpenAPI 3.0。 Up- 开放文档数据,可自由实现接入文档管理系统。
- 支持导出错误码和定义在代码中的各种字典码到接口文档。
- 支持Maven、Gradle插件式轻松集成。
- 支持Apache Dubbo RPC接口文档生成。
- debug接口调试html5页面完全支持文件上传,下载(@download tag标记下载方法)测试。
实现案例
从smart-doc 1.7.9开始官方提供了Maven插件,可以通过在项目中集成smart-doc的Maven插件,然后运行插件直接生成文档。 我们的案例基于smart-doc-maven-plugin,生成文档。示例参考官方配置文档而写。
配置
添加maven的插件
其中./src/main/resources/smart-doc.json是配置文件。
运行测试
可以通过Maven命令生成文档
在IDEA中,也可以通过maven插件构建
maven构建日志如下
构建后的html如下:
也可以看到还自动提供了mock的数据,以及测试接口的按钮。还包含自定义的返回枚举类型等。
展示效果,可以参看https://api.doubans.com/
生成更多类型的文档
smart-doc 还支持生成如下类型的文档:
进一步理解
结合smart-doc官方文档,我们通过几个问题进一步理解smart-doc。主要内容来源于官方文档。
注释信息是有限的,smart-doc如何从注释拓展文档内容呢?
我们知道注释的信息是有限的,swagger技术栈的方式通过定义注解来约束并拓展文档中的内容,那么smart-doc如何从注释拓展文档内容呢?
一方面smart-doc
的实现初衷是通过使用javadoc
文档注释来去除注解式的侵入,因此smart-doc
每增加一个功能首先都是去考虑javadoc
原生的tag
,
下面对smart-doc
使用的一些javadoc
的注释tag
做介绍。
tag名称 | 使用描述 |
| 对于在 |
| 可以在注释中用于标记接口已经废弃,作用同 |
| |
另一方面,原生的tag是不够的,所以smart-doc
又通过自定义tag来支持更多功能的拓展
tag名称 | 描述 |
| |
| 如果你没有使用 |
| 从 |
| 从 |
| 从 |
| 从 |
| 从 |
| 从 |
| 从 |
| 从 |
| 从 |
| |
Maven多模块中使用插件有没有比较好的实践?
在独立的Maven项目中使用smart-doc,当前可以说是如丝般爽滑。但是在Maven的多模块项目中使用smart-doc-maven-plugin时,很多同学就有疑问了, smart-doc插件我到底是放在什么地方合适?是放在Maven的根pom.xml中?还是说各个需要生成API接口文档的模块中呢? 下面就来说说根据不同的项目结构应该怎么放插件。
完全的父子级关系的maven项目:
上面的maven结构假设是严格按照父子级来配置的,然后web1和web2都依赖于common, 这种情况下如果跑到web1下或者web2目录下直接执行mvn命令来编译 都是无法完成的。需要在根目录上去执行命令编译命令才能通过,而smart-doc插件会通过类加载器去加载用户配置的一些类,因此是需要调用编译的和执行命令 是一样的。这种情况下建议你建smart-doc-maven-plugin放到根pom.xml中,在web1和web2中放置各自的smart-doc.json配置。 然后通过-pl去指定让smart-doc生成指定 模块的文档。操作命令如下:
如果不是按照严格父子级构建的项目,还是以上面的结构例子来说。common模块放在类parent中,但是common的pom.xml并没有定义parent。 common模块也很少变更,很多公司内部可能就直接把common单独depoly上传到了公司的Nexus仓库中,这种情况下web1和web2虽然依赖于common, 但是web1和web2都可以在web1和web2目录下用命令编译,这种情况下直接将smart-doc-maven-plugin单独放到web1和web2中是可以做构建生成文档的。
【多模块测试用例参考】
注意: 怎么去使用插件并没有固定的模式,最重要的是熟练Maven的一些列操作,然后根据自己的项目情况来调整。技巧娴熟就能应对自如。 对于插件的使用,从smart-doc-maven-plugin 1.2.0开始,插件是能够自动分析生成模块的依赖来加载必要的源码,并不会将所有模块的接口文档合并到一个文档中。
如果生成文档时遇到问题,该如何调试?
在使用
smart-doc-maven-plugin
插件来构建生成API
文档的过程中可能会出现一些错误问题。官方文档中提供了调试的方案:
- 添加smart-doc依赖
因为smart-doc-maven-plugin
最终是使用smart-doc
来完成项目的源码分析和文档生成的,
通常情况下真正的调试的代码是smart-doc
。但这个过程主要通过smart-doc-maven-plugin
来排查。
注意: 使用smart-doc
的版本最好和插件依赖的smart-doc
版本一致。
- 添加断点
添加断点如图所示
- Debug模式运行构建目标
maven
插件在idea
中运行debug
非常简单,操作如下图。
这样就可以直接进入断点了。
提示: 上面是通过插件去作为入口调试smart-doc
的源码,如果你想调试插件本身的源码执行过程,则将插件的依赖添加到项目依赖中,如下:
然后通过上面的类似步骤调试smart-doc-maven-plugin
的源码
示例源码
https://github.com/realpdai/tech-pdai-spring-demos
https://smart-doc-group.github.io/
更多内容
告别碎片化学习,无套路一站式体系化学习后端开发: Java 全栈知识体系(https://pdai.tech)