这些天项目有的API出现版本控制问题，着实忙乎了一小阵，因为项目使用TP5的传统方法进行版本控制（api目录下进行版本区分，由请求路径决定使用的版本）

但是问题往往是，项目使用了v2版本,但是后端又新建了v3，而前端不知情，所以也趁着这次机会，探索了较为实用的前后端分离问题与解决方案，并做整理。

较明显的问题

1.后端 API 产能不免，供给不上的问题
2.后端 API 出现 BUG，需要等待修复的问题
3.前后端沟通差异导致API实现的偏差
4.后端 API 发生了修改，没有通知到前端，showcase 的时候发现了 bug

问题1解决方案

1.后端规范功能函数集、功能模块集、统一返回格式与方法、提高代码复用率，从而提高后端API产能问题

问题2解决方案

1.API出现BUG，前端提出BUG，并设置修复期限、BUG等级、修复奖励记录
2.API从完成到正式使用有三天使用内测期，内测期内前端发现BUG有奖励记录
3.前端内测期外的API出现BUG次数作限制，超过则惩罚记录
4.后端内测期外的API出现BUG次数作限制，超过则惩罚记录

问题3解决方案

使用API敏捷原型开发方法：
--前端构造理想IO，即参数，返回数据格式等等(半天)
--后端思考实现可行性，调整IO(半天)
--后端实现API(协商时间)，锁定API版本(具体实现参考下面方案)

问题4解决方案

实现一个简易型的消息系统（我们使用了基于swoole实现的websocket，具体可参考我的开源小框架）

1.后端
--API完成
--与前端确认OK，则API锁定版本V1.0（自动记录锁定情况到日志）

2.需求变化/其他变动
--解锁API（自动通知前端,XXAPI版本解锁了），不解锁则无法提交成功
--修改完成后更新API版本，重复步骤1即可

API锁定与版本更新实现方案

概念

• API版本解锁：每个API文件方法头标明版本号，每次修改需修改版本号，即为解锁。
• API版本升级：每个API文件方法头标明版本号，每次修改需修改版本号大于原版本号，即为版本升级。

实现步骤

1.所有API按特定模块归类，例如admin后台模块，在API目录里编写相应的各个API文件，或如上图进行区分
2.记录所有模块API目录的路径到脚本，在开发人员提交的时候对这些路径进行检查
3.编写检查API的脚本，工作流程如下：提交时钩子检查API文件里的API方法是否无解锁的情况下被修改，即提交的文件如果是API目录下的API文件，则该文件方法注释里的版本号是否与原函数一致，一致且函数内容不一样，提交失败并提示
4.如果提交的API文件版本大于原版本，短信通知过前端，提交成功

建议

提交代码时共触发两个脚本，一个做检查，一个做记录（记录前端人员的电话，API目录）

以上为粗略说明，若有错误与更好建议，请留言反馈，谢谢。

创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
基于swoole的实时消息通信框架
基于Fastadmin整合阿里云OSS,Redis,物流，短信的后台系统