# ApiVersion

**Repository Path**: cnxiaoby/ApiVersion

## Basic Information

- **Project Name**: ApiVersion
- **Description**: No description available
- **Primary Language**: C#
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2018-09-17
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

这是什么？
==========

这是一个基于 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”的当前请求在下列操作方法之间不明确”