无规矩不成方圆，为了开发人员间更好的配合，我特意整理了这么一篇文档供大家参考学习，如有意见、见解，请在评论区留言探讨。

接口规范说起来大，其实也就那么几个部分，接口规范、接口管理工具、接口文档编写、开发文档编写。

接口规范定义

一、协议规范

    为了确保不同系统/模块间的数据交互，需要事先约定好通讯协议，如：TCP、HTTP、HTTPS 协议。为了确保数据交互安全，建议使用 HTTPS 协议。

二、接口路径规范

    作为接口路径，为了方便清晰的区分来自不同的系统，可以采用不同系统/模块名作为接口路径前缀。

格式规范如下：

    订单模块  /order/xx

三、版本控制规范

    为了便于后期接口的升级和维护，建议在接口路径中加入版本号，便于管理，实现接口多版本的可维护性。如果你细心留意过的话，你会发现好多框架对外提供的 API 接口中(如：Eureka)，都带有版本号的。如：接口路径中添加类似"v1"、"v2"等版本号。

格式规范如下：

      /xx/v1/xx

更新版本后可以使用 v2、v3 等、依次递加。

四、接口命名规范

可结合【接口路径规范】、【版本控制规范】，外加具体接口命名(路径中可包含请求数据，如：id 等)，建议具体接口命名也要规范些，可使用"驼峰命名法"按照实现接口的业务类型、业务场景等命名，有必要时可采取多级目录命名，但目录不宜过长，两级目录较为适宜。

格式规范如下：

    /user/v1/sys/login     用户服务/模块的系统登录接口

   /zoo/v1/zoos/{ID}        动物园服务/模块中，获取 id 为 ID 的动物

具体接口命名，通常有以下两种方式：

• 接口名称动词前/后缀化

接口名称以接口数据操作的动词为前/后缀，常见动词有：add、delete、update、query、get、send、save、detail、list 等，如：新建用户 addUser、查询订单详情 queryOrderDetail。

• 接口名称动词+请求方式

接口路径中包含具体接口名称的名词，接口数据操作动作以 HTTP 请求方式来区分。常用的 HTTP 请求方式有：

    GET：从服务器取出资源（一项或多项）。

    POST：在服务器新建一个资源。

    PUT：在服务器更新资源（客户端提供改变后的完整资源）。

    PATCH：在服务器更新资源（客户端提供改变的属性）。

    DELETE：从服务器删除资源。

如：

    GET /zoo/v1/zoos：列出所有动物园

    POST /zoo/v1/zoos：新建一个动物园

    GET /zoo/v1/zoos/{ID}：获取某个指定动物园的信息

    PUT /zoo/v1/zoos/{ID}：更新某个指定动物园的信息（提供该动物园的全部信息）

    PATCH /zoo/v1/zoos/{ID}：更新某个指定动物园的信息（提供该动物园的部分信息）

    DELETE /zoo/v1/zoos/{ID}：删除某个动物园

    GET /zoo/v1/zoos/{ID}/animals：列出某个指定动物园的所有动物

    DELETE /zoo/v1/zoos/ID/animals/ID：删除某个指定动物园的指定动物

五、请求参数规范

• 请求方式：

• 请求头：

• 请求参数/请求体：

请求参数字段，尽可能与数据库表字段、对象属性名等保持一致，因为保持一致最省事，最舒服的一件事。

六、返回数据规范

    统一规范返回数据的格式，对己对彼都有好处，此处以 json 格式为例。返回数据应包含：返回状态码、返回状态信息、具体数据。

格式规范如下：

{

    "data": {

        //json 格式的具体数据

}

返回数据中的状态码、状态信息，常指具体的业务状态，不建议和 HTTP 状态码混在一起。HTTP 状态，是用来体现 HTTP 链路状态情况，如：404-Not Found。HTTP 状态码和 json 结果中的状态码，并存尚可，用于体现不同维度的状态。

接口管理工具推荐

接口开发完后，最终的目的是提供给其他系统/模块来使用的，因此，接口的管理是必不可少的。

接口的管理常常面临很多的痛苦，这里就列举几个常见的，看看你是否也遇到过。

• 系统/模块太多、接口太多，没有系统统一管理所有接口。

• 代码修改后，接口文档没有及时更新，造成接口文档和实际接口不一致的现象。

• 接口管理系统自主研开发成本高。

• 接口管理缺少接口 mock 功能。

在日常工作过程中用过、接触过的接口管理工具也是不尽其数，下面介绍你可能使用过、没有使用过的接口管理工具，同时也介绍这些接口管理工具的优缺点。   

word

    相信大家之前用来管理接口比较多的应该是 word 吧，开发人员将系统的接口维护在 word 文档里，不管是组内沟通还是和其他团队的接口沟通都离不开这些接口文档，每次修改文档和代码都要同步修改。相信使用 word 的缺点大家应该也很清楚，就是维护和管理很麻烦，我们经常会遇到文档和代码不一致的情况，大部分不一致都是因为接口因为种种原因修改了，开发人员大部分都是只改了代码里的接口实现，而没有去修改接口文档。而且 word 文档搜索接口也很麻烦，没办法建全局索引，只能一个个文档点开查看，想想就很痛苦。但不可否认的是，word 对于一些小团队用起来还是挺方便的，不用搭建系统，给谁一看就明白。

自建接口管理系统

    对于一些有一定规模的企业，在各项工程管理活动上都非常正规，各种 ISO 标准要遵守，自然对接口管理的要求也非常高，之前在国有银行，我们就是自建了接口管理系统，自建还是很消耗人力成本的，从开发到后续运维，都要消耗人力，但是自建的好处就是，可以根据公司的要求进行各种花样的定制，我们之前在接口管理系统中加入了很多好用的定制功能，例如接口被哪些系统调用、接口是在哪个批次投产又在哪个批次做过变更等等，这对于架构师来说非常好用，用于分析接口影响范围非常方便。目前开源的接口管理系统还没有能做到这些定制化功能的。

wiki

之前在小团队的时候还用过一段时间的私有 wiki，wiki 特别适合于小团队高速线性迭代开发，在 wiki 上看到的就是最新的接口，团队内所有成员看到的都是一样的，如果接口有变化，相关开发人员修改后立即生效，保证了顺畅的接口沟通。但是 wiki 的缺点也很多，接口文档只是静态页面，无法实现一些动态效果，无法实现追溯等等缺点。

RAP

相信很多互联网公司都在使用 RAP，RAP 是阿里开源的一套接口管理系统，RAP 可以比较方便的管理公司所有系统的接口，同时还有比较完善的权限管理，还可以做接口 mock，方便开发人员在接口功能还没有完成的时候能够及时发布出去，给调用方去使用。但是 RAP 的缺点就是每个接口都需要维护进去，接口修改后也需要及时维护，当时我们在使用的时候遇到的最大的问题也是经常碰到接口没有及时维护的问题。

swagger

看了那么多 swagger 的优点，下面也说说 swagger 的缺点，那就是 swagger 是跟随着每个工程一起启动的，这就导致每个工程都有一个 swagger 的访问地址，如果公司系统很多的话，那就会导致查看不同系统的接口都要到不同的地址去查看，每个开发都要自己收藏好各个系统的 swagger 地址。有些公司也自己开发了统一网关，将所有 swagger 的接口地址聚合起来，但是多少还是涉及到一些开发工作的，而且做的还不一定很完善。

Easy Mock

官网的这张图基本上介绍清楚了 easymock 的核心功能，这其中我最看重的功能有两块，一个是能够集成 swagger 接口并集中管理所有接口，另一个就是响应式数据。

EasyMock 能够根据 swagger 接口的地址自动导入所有 swagger 接口，非常方便，对于非 swagger 的接口也可以手工维护进去，这样可以很方便的做到全公司接口统一维护，而且也有比较完善的接口权限管理，方便分组管理。但缺点就是过于庞大，可能太适合小一点项目或团队。

上面提及到接口管理工具，大家可根据自己项目的规模、需求，进行实际选择，切记生搬硬套。