PHP 开发的 API 多版本管理实践

遇到的情况

本文针对移动互联网客户端需要兼容旧版的情况，强制升级到最新版本的 app 不在讨论之列。

在 bugtags.com 项目中，我们的版本遵循下面规范。
1.0.1
大功能.小更新.bug 修正
我们的版本列表如下：

1.0、1.1、1.2、1.3、1.4
2.0、2.1、2.2、2.3
3.0、3.1
…
5.0

这样一个版本结构，所有版本都可以用，跨度最大时，1.0 用户要跟 5.0 用户并存。
以 /api/user/info 接口举例，经过这么多版本的迭代，版本 1.0 跟 3.0 的返回数据结构可能已经完全不同了。
对于这样一个系统，如何设计一个完备的版本架构非常重要。

移动互联网，有别于传统的 web 开发。其快速迭代、版本升级与传统的 web 开发相比，有如下困难：

版本号用域名是比较不被认同的方案，主要原因是域名管理往往跨部门，增加了沟通成本。
http 头是我个人最赞同的一种方式，可以保持 url 的整洁。
url 参数中携带版本号的方式也很好，但是要注意不要跟业务逻辑的参数名重复。

优点，随时切换分支成本低，尤其在 git 管理代码时。
缺点，如果多个版本需要修改时，代码合并工作量大。

优点，代码的总体规模小（只有一份代码）
缺点，在需要判断版本的地方会有大量的分支语句

最后的解决办法充分利用了 php 的 autoload 加载机制和命名空间。

PHP 开发的 API 多版本管理实践

举例说明

v10 提供 a,b,c 三个接口
v20 提供 a1,b,c 三个接口, a1 是 a 的修改
v30 提供 a,b1,c 三个接口, b1 是 b 的修改

用下面三段代码来具体描述

<?php

/**

 * View/Api/Base/Config/Config.php

 */

namespace View\Api\Config;

class Config {

    function index(){echo __METHOD__;}

}

?>

<?php

/**

 * View/Api/V10/Config/Config.php

 */

namespace View\Api\Config;

class Config {

    function index(){echo __METHOD__;}

}

?>

<?php

/**

 * View/Api/V20/Config/Config.php

 */

namespace View\Api\Config;

class Config {

    function index(){echo __METHOD__;}

}

?>

配置版本：

用户要访问 /api/user/info?ver=3.0.1 此时，类的加载顺序依次为:

这是限制只能继承一层的原因是尽可能的降低系统的复杂度。这种方式管理代码已经在几个项目中得到一些验证。系统代码的复杂度可以很大程度上降低，尤其是多个版本迭代、又不能强制升级的系统中。另外需要注意的就是 :

笔者在开发和运营 bugtags.com ，这是一款能够极大的提升 app 开发者测试效率的 SDK 产品，欢迎使用、转发推荐。

PHP 开发的 API 多版本管理实践