Prototype功能预览十三：一个注解完成更加规范的API版本管理-极大减少dubbo框架频繁修改接口问题

框架整体介绍：http://blog.csdn.NET/flyxxxxx/article/category/7055640

对此框架有兴趣或想参与开发的请加QQ群：255195191

在APP开发过程中，经常会出现同一功能接口，在不同迭代中有更新的问题，如下表所示：

“创建”表示后端接口在此迭代中创建，“更新”表示接口有变化

迭代版本/API接口ABCDE1.0创建创建   1.1  创建  1.2更新为1.2 更新为1.2创建 1.3 更新为1.3 更新为1.3创建1.4  更新为1.4 更新为1.4

后端使用Prototype框架，要求APP端在请求所有的URL时，在HTTP请求头中加入一个API版本变量，这个变量对于每个APP的版本，所有的接口与迭代版本一致。

当发布1.0版本时，后端只提供了接口A和B

当发布1.1版本时，后端提供了接口C，1.1版本的APP访问A或B接口时，后端收到的版本号为1.1，后端发现这两个接口没有1.1版本，请求将自动转发到最近的版本1.0

当发布1.2版本时，A和C接口有更新，1.2版本的APP访问这两个接口时，后端将调用对应的1.2版本的接口，1.1版本的APP访问这两个接口时，因HTTP请求中的版本号不会发生变更，还是1.1，因此按规则，后端给A接口提供的是1.0版本的访问，给C接口提供的是1.1版本的访问（C接口不存在1.0版本）

以此类推，每个APP调用的后端接口版本总是与它发布时的API接口版本一致。

Prototype中，定义版本号只需要一个注解（当然业务类名可能不同）：

@Service(desc="发送邮件",version="1.3")

public class SendMail1_3 extends Business{...}

在阿里dubbo框架的支持中，Prototype框架可自动为不同版本生成客户端代码，因此当接口发生变化时，并不需要把所有依赖的工程重新编译打包。

当然，在开发环境中，因为接口版本号没有变化，可能还需要编译打包的工作，但按照Prototype框架的最小化接口原则，接口的输入输出是通过注解定义的，没有定义的对象的属性的变更（增加或减少）不会造成接口的变量，因此同样可以减少开发过程中频繁编译打包接口的问题。