在前后端分离框架中,API 文档频繁交接。如果涉及到第三方接口调用,多方合作场景下,API 和文档变更可能会更快。为了方便维护 API 和交接文档,这里给大家推荐一款文档生成工具 - apidoc
1.apidoc 简介
apidoc 是一个基于 nodejs 的 API 文档生成工具,从代码注释中提取特定格式的内容,生成 API 文档。
目前支持的语言有:C#、C/C++、D、Erlang、Go、Groovy、Java、Javascript、Pascal/Delphi、Perl、PHP、Python、Rust、Ruby、Scala 和 Swift。
特点:
- 跨平台,linux、windows、macOS 等都支持。
- 支持语言广泛。
- 支持文档版本管理。
- 支持多个不同语言的多个项目生成一份文档。
- 输出模板可自定义。
2. 举个例子
以 Django 为例,在 views 函数中写注释
|
|
生成的 API 文档
3. apidoc 支持的关键字
apidoc 通过抽取代码注释,根据关键字语法生成 API 文档。所以,如果想生成理想的 API 文档,一定要遵循 apidoc 的相关关键字语法。下面是一个关键字语法的 list,{ }表示需要替换的变量,[ ]表示可选参数:
- @api {method} path [title]。
只有使用@api 标注的注释块才会在解析之后生成文档,title 会被解析为导航菜单(@apiGroup)下的小菜单
method 可以有空格,如{POST GET} - @apiGroup name。
分组名称,被解析为导航栏菜单 - @apiName name。
接口名称,在同一个@apiGroup 下,名称相同的@api 通过@apiVersion 区分,否者后面@api 会覆盖前面定义的@api - @apiDescription text。
接口描述,支持 html 语法 - @apiVersion verison。
接口版本,major.minor.patch 的形式 - @apiIgnore [hint]。
apidoc 会忽略使用@apiIgnore 标注的接口,hint 为描述 - @apiSampleRequest url。
接口测试地址以供测试,发送请求时,@api method 必须为 POST/GET 等其中一种 - @apiDefine name [title] [description]。
定义一个注释块(不包含@api),配合@apiUse 使用可以引入注释块
在@apiDefine 内部不可以使用@apiUse - @apiUse name。
引入一个@apiDefine 的注释块 - @apiParam [(group)] [{type}] [field=defaultValue] [description]。请求参数
- @apiHeader [(group)] [{type}] [field=defaultValue] [description]。头部参数
- @apiError [(group)] [{type}] field [description]。响应错误时参数
- @apiSuccess [(group)] [{type}] field [description]。成功时参数,
group 表示参数的分组,type 表示类型(不能有空格),入参可以定义默认值(不能有空格) - @apiParamExample [{type}] [title] example。参数请求用例
- @apiHeaderExample [{type}] [title] example。头部请求用例
- @apiErrorExample [{type}] [title] example。错误请求用例
- @apiSuccessExample [{type}] [title] example。成功请求用例
type 表示的是 example 的语言类型, example 内容会被直接解析显示。 - @apiPermission name。
name 必须独一无二,描述@api 的访问权限,如 admin/anyone
4. 安装配置 apidoc
- 安装 apidoc
这里默认已经安装了 nodejs,如果没有安装,请自行下载安装。全局安装 apidoc:
|
|
- 配置
配置是可选的,没有配置并不影响文档的生成。只是缺失部分 API 文档信息而已。在工程的根目录下,创建 apidoc.json 文件,配置文档的基本信息:
|
|
- 生成文档
在 apidoc.json 所在的目录下,执行命令:
|
|
-i 参数表示输入的目录,默认生成的文档在当前目录下的/doc,也可以通过-o 参数指定。
5. apidoc 自动生成
每次更新代码注释之后,执行一次**apidoc -i ./**才能看到 API 文档,比较麻烦。能不能每次修改注释之后,自动生成 API 文档呢?当然可以。
- 安装 gaze
gaze 是基于 nodejs 的文件监控项目。
|
|
- 编写监控代码
apidoc-watch.js
|
|
- 执行监控
只需要更新注释之前,执行一次命令即可。
|
|
6. 项目实践建议
6.1 文档的交接方式
建议将 API 文档生成在前端的 static 目录下,以链接的形式交接,比如: htttp://example.com/static/doc/index.html。
6.2 后端注释组织方式
以 Django 为例,由于 apidoc 需要的注释量比较大,有两种选择:
- 一种是将注释直接写在每个 views 函数中,
- 一种是单独使用一个文件或文件夹来写注释。
django 中建议skinny controller, fat model,views.py 中少些代码,多写注释,第一种方案比较合适。同时,注释和接口实现放在一起,可以降低二次维护学习成本。
6.3 使用 apiDefine 和 apiUse
由于前后端,常常会约定固定格式的返回。可以将格式固定的部分,使用 apiDefine 定义为一个注释块,在其他地方使用 apiUse 引用。可以有效减少注释量。
定义注释块,注意:一个注释块应该被定义为一个单独的注释:
|
|
其他地方引用
|
|
6.4 合理使用 apiGroup 分组
apiGroup、apiName 会被拼接到 URL 中,比如:static/doc/index.html#api-apiGroup-apiName。给 apiGroup、apiName 取个容易理解的名字很重要。合理使用 apiGroup,将前端相关的功能聚集在一起,有利于前端理解 API 的用途。