这是什么？
这是一个基于 ASP.NET MVC (.NET 4.5) 的一个类RESTFul风格的 API Server，运用继承、重载的**实现API版本的增量控制。
为什么需要？
在快速迭代、版本升级过程中，我们的API版本遵循如下规范：
1 .0 .0
大版本 .小更新 .BUG修复
1.0
1.1
2.0
2.0.8
3.0
版本经过这么多的迭代，所有版本都可用，1.0 要跟 3.0 共存，而版本 1.0 跟 3.0 的返回数据结构可能已经完全不同了。对于这样一个API Server，如何设计版本控制架构呢？
此外迭代的中还需要处理到以下问题：
- 多个版本共存，服务器端代码量巨大，维护成本倍增
- 对于频繁的BUG修正，如何降低改动范围
架构目的
- 缩小服务端的代码规模
- 简化版本管理过程
核心**
利用继承、重载的**降低服务器端代码量，实现灵活的版本控制
v1.0 为第一个版本，也是所有业务的基础
v1.1 版本是继承 v1.0 版本开发的，并提供特有的业务服务A，输出用户信息A
v1.1.1 版本是继承 v1.1.1 版本开发，并重载了业务服务A，输出用户信息A和用户信息B
v2.0 版本是继承 v1.1 版本开发的，并关闭业务服务A，增加特有业务B，而用户使用v1.1版本的时候业务服务A仍然可用
......
更新记录
2017-03-14
- 增加 HelpPage 接口描述文档，访问地址：http://localhost:81/help
- 增加[VersionActionNameSelector]特性，修复同名方法覆盖（new），修复异常：“对控制器类型“DefaultController”的操作“index”的当前请求在下列操作方法之间不明确”