如何写好接口文档？

1 HTTP携带信息的方式

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

2 分离通用信息

通常来讲，headers里的信息都是通用的，能够提早说明，做为默认参数

3 路径中的参数表达式

URL中参数表达式使用mustache的形式，参数包裹在双大括号之中{{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），通常意义上说软件 = 数据 + 算法, 可是我认为文档也是一种组成软件的重要形式。既然软件须要版本管理，文档的版本管理也是比不可少的。