如何写好接口文档?

1. HTTP携带信息的方式

  • url
  • headers
  • body: 包括请求体,响应体

2. 分离通用信息

一般来说,headers里的信息都是通用的,可以提前说明,作为默认参数

3. 路径中的参数表达式

URL中参数表达式使用{}的形式,参数包裹在大括号之中{paramName}

例如:

  • /api/user/{userId}
  • /api/user/{userType}?age={age}&gender={gender}

4. 数据模型定义

数据模型定义包括:

  • 路径与查询字符串参数模型
  • 请求体参数模型
  • 响应体参数模型

数据模型的最小数据集:

  • 名称
  • 是否必须
  • 说明

“最小数据集”(MDS)是指通过收集最少的数据,较好地掌握一个研究对象所具有的特点或一件事情、一份工作所处的状态,其核心是针对被观察的对象建立起一套精简实用的数据指标。最小数据集的概念起源于美国的医疗领域。最小数据集的产生源于信息交换的需要,就好比上下级质量技术监督部门之间、企业与质量技术监督部门之间、质量技术监督部门与社会公众之间都存在着信息交换的需求。

一些文档里可能会加入字段的类型,但是我认为这是没必要的。以为HTTP传输的数据往往都需要序列化,大部分数据类型都是字符串。一些特殊的类型,例如枚举类型的字符串,可以在说明里描述。

另外:数据模型非常建议使用表格来表现

举个栗子🌰:

名称 是否必须 说明
userType 用户类型。commom表示普通用户,vip表示vip用户
age 用户年龄
gender 用户性别。1表示男,0表示女

5. 请求示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// general 
POST http://www.testapi.com/api/user

// request payload
{
"name": "qianxun",
"age": 14,
"like": ["music", "reading"],
"userType": "vip"
}

// response
{
"id": "asdkfjalsdkf"
}

6. 异常处理

异常处理最小数据集

  • 状态码
  • 说明
  • 解决方案

举个栗子🌰:

状态码 说明 解决方案
401 用户名密码错误 检查用户名密码是否正确
424 超过最大在线数量 请在控制台修改最大在线数量

之前我一直不想把解决方案加入异常处理的最小数据集,但是对于很多开发者来说,即使它知道424代表超过最大在线数量。如果你不告诉如果解决这个问题,那么他们可能就会直接来问你。所以最好能够一步到位,直接告诉他应该如何解决,这样省时省力。

7. 如何组织?

7.1. 一个创建用户的例子:创建用户

1 请求示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// general 
POST http://www.testapi.com/api/user/vip/?token=abcdefg

// request payload
{
"name": "qianxun",
"age": 14,
"like": ["music", "reading"]
}

// response
{
"id": "asdkfjalsdkf"
}

2 路径与查询字符串参数模型

POST http://www.testapi.com/api/user/{userType}/?token={token}

名称 是否必须 说明
userType 用户类型。commom表示普通用户,vip表示vip用户
token 认证令牌

3 请求体参数模型

名称 是否必须 说明
name 用户名。4-50个字符
age 年龄
like 爱好。最多20个

4 响应体参数模型

名称 说明
id 用户id

5 异常处理

状态码 说明 解决方案
401 token过期 请重新申请token
424 超过最大在创建人数 请在控制台修改最大创建人数

7.2. 这样组织的原因

  1. 请求示例: 请求示例放在第一位的原因是,要用最快的方式告诉开发者,这个接口应该如何请求
  2. 路径与查询字符串参数模型: 使用mustache包裹参数
  3. 请求体参数模型:如果没有请求体,可以不写
  4. 响应体参数模型
  5. 异常处理

8. 文档提供的形式

文档建议由一下两种形式,在线文档pdf文档

  • 在线文档
    • 更新方便
    • 易于随时阅读
    • 易于查找
  • pdf文档
    • 内容表现始终如一,不依赖文档阅读器
    • 文档只读,不会被轻易修改

其中由于是面对第三方开发者,公开的在线文档必须提供;由于某些特殊的原因,可能需要提供文件形式的文档,建议提供pdf文档。当然,以下的文档形式是非常不建议提供的:

  • word文档
  • markdown文档

word文档和markdown文档有以下缺点:

  • 文档的表现形式非常依赖文档查看器:各个版本的word文档对word的表现形式差异很大,可能在你的电脑上内容表现很好的文档,到别人的电脑上就会一团乱麻;另外markdown文件也是如此。而且markdown中引入文件只能依靠图片链接,如果文档中含有图片,很可能会出现图片丢失的情况。
  • 文档无法只读:文档无法只读,就有可能会被第三方开发者在不经意间修改,那么文档就无法保证其准确性了。

总结一下,文档形式的要点:

  • 只读性:保证文档不会被开发者轻易修改
  • 一致性:保证文档在不同设备,不同文档查看器上内容表现始终如一
  • 易于版本管理:文档即软件(DAAS: Document as a Software),一般意义上说软件 = 数据 + 算法, 但是我认为文档也是一种组成软件的重要形式。既然软件需要版本管理,文档的版本管理也是比不可少的。