简介
做开放平台供外部调用的Api理论上变化越少针对调用者来讲越有利，随着开放平台的功能不断完善（优化）不可避免的需要添加新的资源，或者修改现有资源。因此Api的更新升级必不可少，但是，对于开放平台来讲从一开始就应该将对外提供的Api加入版本管理。一个长期稳定可用的开放平台才能被越来越多的用户使用。
同理，Native的App与服务器Api也存在同样的关系，Native App安装在不同的移动设备上，如果Api变动都需要提示用户进行强制更新来适配新版本的Api接口，那么，App用户将异常烦躁甚至于将App从设备中Uninstall掉。
查看众多论坛与博客，总结出目前实现有三种方式：
- URI
在访问Api中增加version段来告诉服务器所使用的Api版本（如：http://xxxx/api/customers/v1.1/1234 ）。 这种方式正是由于在uri中增加了version段，破坏掉了Api的统一访问URL。 - Request Parameter
在Api后增加请求参数来告诉服务器所使用的Api版本（如：http://xxxx/api/customers/1234?v=1.1 ）这种方式与第一种URI的方式类似。 - Request Header
在请求Api时在Request的请求头中增加Version值来告诉服务器所使用的Api版本。这种方式保留了Api统一访问的URL，版本号传递更隐秘。但需要客户端在请求时增加此参数来完成，所以需要App在开发之初就需要增加版本号的传递。
综上所述，个人认为第三种 Request Header的传递方式具有统一了URL和Version段隐秘的优点，为最适合的传递方式。
Request Header方式实现版本控制
说完了客户端传递版本号的方式之后，我们来看一下服务端的处理。按流行的MVC的方式来看，个人觉得应该在控制层之前增加Api的版本控制层来先对客户端的请求Api进行版本的预判。
个人总结了一下，有以下几种预判结果：
1: Api为所有版本提供服务。
2: Api提供了最低版本，为大于此最低版本的请求提供服务。
3: Api提供了服务的版本范围，为大于最低版本且小于最高版本的请求提供服务。
4: Api已过期，由其它的Api代替。
5: Api已废弃不再提供服务。
按以上思路，按Java实现为例。可以通过 自定义注解（Annotation）+ 过滤器（Filter）实现。
相似的方案还有：自定义注解 + 拦截器， 自定义注解 + Spring AOP
同理，其它的语言均有类似技术可以实现。
接下来我将在 https://github.com/stotem/header-version-filter.git 中公布我的Annotation+Filter实现。
观点仅代表自己，期待你的留言。