接口设计评审规范

前言

本接口设计规范，参考了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:总共页数

金额参数

统一以分为单位进行传递

时间参数

建议统一以时间毫秒数进行传递，避免前后端或者各种场景下日期格式不统一