同学们学习python的时候接口文档是比较重要的，接口文档的问题直接影响到我们后续接口的调用以及使用，那么下面我们一起来认真学习下如何写好接口文档。
# 1 HTTP携带信息的方式
- url
- headers
- body: 包括请求体，响应体
# 2 分离通用信息
一般来说，headers里的信息都是通用的，可以提前说明，作为默认参数
# 3 路径中的参数表达式
URL中参数表达式使用[mustache](https://github.com/janl/mustache.js)的形式，参数包裹在双大括号之中`{{paramName}}`
例如：
- `/api/user/{{userId}}`
- `/api/user/{{userType}}?age={{age}}&gender={{gender}}`
# 4 数据模型定义
数据模型定义包括：
- 路径与查询字符串参数模型
- 请求体参数模型
- 响应体参数模型
数据模型的最小数据集：
- 名称
- 是否必须
- 说明
> “最小数据集”（MDS）是指通过收集最少的数据，较好地掌握一个研究对象所具有的特点或一件事情、一份工作所处的状态，其核心是针对被观察的对象建立起一套精简实用的数据指标。最小数据集的概念起源于美国的医疗领域。最小数据集的产生源于信息交换的需要，就好比上下级质量技术监督部门之间、企业与质量技术监督部门之间、质量技术监督部门与社会公众之间都存在着信息交换的需求。
一些文档里可能会加入字段的类型，但是我认为这是没必要的。以为HTTP传输的数据往往都需要序列化，大部分数据类型都是字符串。一些特殊的类型，例如枚举类型的字符串，可以在说明里描述。
另外：`数据模型非常建议使用表格来表现`。
举个栗子?：
| 名称 | 是否必须 | 说明 |
| -------- | -------- | ------------------------------------------------ |
| userType | 是 | 用户类型。`commom`表示普通用户，`vip`表示vip用户 |
| age | 否 | 用户年龄 |
| gender | 否 | 用户性别。`1`表示男，`0`表示女 |
# 5 请求示例
```
// 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 请求示例**
```
// 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），一般意义上说`软件 = 数据 + 算法`, 但是我认为`文档也是一种组成软件的重要形式`。既然软件需要版本管理，文档的版本管理也是比不可少的。