为什么需要接口管理平台

前言

随着web技术的不断发展，互联网产品的开发模式也从原始的后端逻辑为主发展到前端后端移动端三分天下的局面。因此，后端如何能提供更多、更灵活的服务给其他同学（前端|移动端|其他三方）成为了开发者的问题，相对于其他rpc服务，http这样的无状态协议成为了开发者的选择，restful,graphQL因此成为现阶段开发的主流，从而激发了前后端分离浪潮，让各端同学各司其职、分工协作被细化，从而提高了编码效率；

现状

但是，使用基于http服务的接口来进行开发，也带来了一些额外的问题，其中之一就是随着业务功能的不断增多，后端同学提供出来的api也会越来越多。

试想这样一个例子：当我们的产品同学提出，要修改一个一年前上线的功能，这个时候前后端要怎么做，我们只能先看看代码，看对应的接口是用来做什么的，返回了什么字段，对应字段和数据库是怎么对应的来猜出其的意义，然后想想该如何修改，等开发完成后在通知测试进行测试。

在这个流程中，前端以及测试基本处于黑盒状态，无法知道所提供的接口里面具体需要的东西，经常遇到问题是接口因未知原因增加参数了，参数名变了，参数被删除了，这也给前端和测试带来了很多麻烦。

基于上面的问题，发展出了基于wiki、word等文档接口记录方式，我们通过在文件记录接口的方式将接口存档，以便下次查看和修改，可能部分同学的接口文档向这样

image.png

这样初步对接口进行了简单的管理，不论是新人，历史接口都能很快的去理解接口的作用，但是文件的管理方式也并没有完全的解决以下几类问题

1. 无法复用数据模型，依赖于复制粘贴的方式

前端同学应该都能感受到，后端提供出来的不同的接口可能会依赖相同的数据结构，通过文件管理，那么我们就会大量的复制粘贴，影响整体管理效率。

2. 无法提供便捷的查询方式

文件系统困扰是我们只能通过ctrl+f的形式来查询具体关键字，同时也不能模糊,拼音缩写等形式，后期接口增多，难以快捷的查询自己

3. 难以进行接口版本管理

互联网崇尚的是敏捷开发，会将功能通过不同迭代的方式，逐步完成开发,因此文件系统如果要进行版本，可能最好的方式就是分文件，可是分文件的又会带来查询不变的问题

4. 不能进行数据Mock

对前后端分离而言，前后端定义了接口后，前端同学一般会根据接口返回的数据接口模拟一份数据出来便于本地开发，但是，这样的模拟并不方便，开发和联调可能需要2套不同的代码，改起来非常恶心

5. 无法利用以定义的接口进行自动化接口测试

基于文本的原因，我们定义的接口并不能利用系统进行自动化接口测试（当然自行编写是可行的）

改进

针对以上现状，不愿意做出重复劳动的开发同学开始针对这样的这种场景，开发了接口管理平台，现在市面上常用的有YApi、Swagger等，这里不在赘述，今天我来介绍一款笔者常用的接口管理平台nei

这个平台是网易云音乐开发，在内外部也承接了各种各样的业务，可以放心应用与各种各样的接口管理场景

通过打开官网我们知道NEI提供了以下的基础服务

image.png

1. 接口规范

即我们常见的接口定义，我们通过定义数据模型以及配置数据生成规则[可选]来对接口进行定义

2. 团队协作

在nei平台之中，可以方便的给团队成员赋能，以提供各式各样的操作阅读权限

3. 工程规范

nei提供了工程规范模板，可以方便的自定义自己的规范来快速导出项目

4. 构建工具

平台提供了自动构建工具，可以自动开启本地接口服务，渲染ejs,ftl等页面模板

5. 接口Mock

接口管理平台的核心功能了，在前后端分离项目，数据的快捷mock可以无缝的进入业务开发

6. 接口测试

接口测试功能可以简单的对线上、测试环境进行接口测试，判断接口返回是否和定义类型相同

简单体验

注册完账号后，我们可以在项目管理中新建一个项目，如test

创建项目.gif

我们的接口，数据模型等都是基于该项目来创建，同时我们也可以额针对该项目设置对应的项目规范等，现在我们来创建一个简单接口

创建接口.gif

在接口创建中，我们可以针对设置该接口的类型，url,请求方式，参数等。

那么，这个接口对前端而言，要如何使用呢？我们可以通过使用平台配套工具nei-toolkit，将线上定义的接口模型mock到本地的方式进行使用我们首先安装该工具

npm install nei –g

使用nei-toolkit功能时，我们需要给我们的项目设置工程规范，这里我们创建一个简单的java工程规范并指定mock目录

创建绑定工程规范.gif

随后执行以下命令

nei build -key xxx

key具体值可以在项目设置中找到

image.png

执行完成后我们可以在目录中找到这样的目录结构

image.png

最后的server.config.js就是我们配置的接口以及相关的返回数据了

我们在执行该命令，即可将对应接口服务器启动起来

nei server -o ./

image.png

我们就可以看到我们定义的接口以及页面，点击对应的连接我们就可以直观的看到对应的数据

image.png

那么这些数据对前端而言，在开发时要如何使用？

1. 基于webpack-dev-server, 我们可以在poxy配置中，将匹配头代理到localhost:8002上
2. 基于本地nginx，我们也可以对具体接口代理到本地的localhost:8002上
3. 如果不是用nginx或者不是webpack-dev-server,我们可以用charles来对接口进行代理，代理到本地具体文件（nei生成的本地文件，如图）

image.png

后记

当然，nei还有很多功能比如单元测试，比如接口规范，团队管理等，这里就不在演示了，本文主要是为了解决前后端分离开发的接口问题而写的文章，也欢迎大家将自己的解决方案共享出来，如果文章对你有用，不妨点个关注，谢谢啦！