接口设计评审规范 - 简书
接口设计评审规范
前言
本接口设计规范，参考了restfull的部分设计理念。
以资源为中心的接口设计
资源是 Restful API的核心元素，所有的操作都是针对特定资源进行的。
任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：
- 某用户的手机号码
- 某用户的个人信息
- 最多用户订购的GPRS套餐
- 两个产品之间的依赖关系
- 某用户可以办理的优惠套餐
- 某手机号码的潜在价值
Github 可以说是这方面的典范，下面我们就拿 repository来说明。
/users/:username/repos
/users/:org/repos
/repos/:owner/:repo
/repos/:owner/:repo/tags
/repos/:owner/:repo/branches/:branch
我们可以看到几个特性：
- 资源分为单个文档和集合，尽量使用复数来表示资源，单个资源通过添加 id 或者 name 等来表示
- 一个资源可以有多个不同的 URL
- 资源可以嵌套，通过类似目录路径的方式来表示，以体现它们之间的关系
接口命名规则
接口名称及简介
接口名称应简单明了，望文知意，接口简介中，需描述清楚接口的具体业务功能。
接口的uri
原则上，接口命名规范整体采用“名词”+“动词”形式
接口返回或者操作的是单个资源对象，采用名称的单数形式命名，如：/user/add，/user/del，/user/get
接口返回或者操作的是多个资源对象，采用名称的复数形式命名，如：/users/get
接口版本
针对同一个接口，根据实际业务需求，为解决接口兼容性问题，可以对接口进行版本扩展，命名规范为“名词”+“动词”+“版本号”形式，版本号采用v1、v2、v3形式命名
例：/user/login ，/user/login/v1
接口返回值
接口返回值，将统一采用如下格式：
{
"sign": "f64b967289ac4d8cbfdc22ad30ec9d09",
"content": "{}",
"timestamp": 1561204602005,
"desc": "成功!",
"code": "000",
"accessToken": "83BAED4DAE9DEF783FDE243F4B5C"
}
sign:返回值签名验签（如果需要）
如遇第三方合作等特殊情况，根据实际情况进行设计。
其他规则
单一职责原则
一个接口只做一件事情
接口中使用连字符"-"代替下划线"_"的使用
连字符"-"一般用来分割URI中出现的字符串(单词)，来提高URI的可读性，使用下划线"_"来分割字符串(单词)可能会和链接的样式冲突重叠，而影响阅读性。
接口中统一使用小写字母
根据RFC3986定义，URI是对大小写敏感的，所以为了避免歧义，我们尽量用小写字符。
同一业务概念需名称统一
例，针对金额，都统一为amount，而不是有的amount，有的money。
接口兼容性
如是对老接口进行改动，需考虑接口的兼容性，包括字段的增减、字段名称调整、字段类型的调整、字段值内容长度的调整，字段值取值范围的调整等。
拼写准确
接口一旦发布就不易修改，要保持兼容性，拼写错误也不能改了，所以要仔细检查拼写。
著名悲剧：unix 的 creat。
creat是一个函数，可以用来创建一个文件并以只写的方式打开。
参数命名
参数命名最好是定语+名词
比如 fileName, maxSize, textColor，而不是用name、size、colour
不要用生僻单词
不要用生僻单词，也不要用汉语拼音
不要自己发明缩写
除非是约定俗成已经被广泛使用的缩写，否则老老实实用完整拼写。
保持方法的对称性，有些方法一旦出现就应该是成对的，
比如 有open就要有close，有login就要有logout，这些单词基本是固定搭配的，使用者就很容易理解。
接口中不允许有is判断
例，业务需要vip用户，接口不允许设计为isVipUser，而应该设计为获取用户的会员等级接口，/user/level/get，这样保证接口的通用性和扩展性
分页接口参数
分页相关接口参数命名统一：
pageSize:每页记录条数
pageNum:当前页数
totalPageNum:总共页数
金额参数
统一以分为单位进行传递
时间参数
建议统一以时间毫秒数进行传递，避免前后端或者各种场景下日期格式不统一