此篇是写给新手的Demo，用于参考和借鉴，用于发散思路。老鸟可以忽略了。
自己经常有这种情况，遇到一个新东西或难题，在了解和解决之前总是说“等搞定了一定要写篇文章记录下来”，但是当掌握了之后，就感觉好简单呀不值得写下来了。其实这篇也一样，决定写下来是想在春节前最后再干一件正经事儿！
目录：
一、请求响应的设计
RESTFul风格响亮很久了，但是我没用过，以后也不打算用。当系统稍微复杂时，为了符合RESTFul要吃力地创建一些不直观的名词，这不是我的风格。所以此文设计的不是RESTFul风格，是最常用的POST和GET请求。
请求部分就是调用API的参数，抽象出一个接口如下：
public interface IRequest { ResultObject Validate(); }这里面只定义了一个Validate()方法，用于验证请求参数的有效性，返回值是响应里的东西，下面会讲到。
对于请求对象，传递到业务逻辑层，甚至是数据访问层都可以，因为它本身就是用来传输数据的，俗话叫DTO(Data Transfer Object)，不过定义多层传输对象，然后复制来复制去也是可以的~。但是有时候业务处理会需要当前登录人的信息，而这个信息我并不希望直接从接口层向下传递，所以这里我再抽象一个UserRequestBase，用于附加登录人相关信息：
public abstract class UserRequestBase : IRequest { public int ApiUserID { get; set; } public string ApiUserName { get; set; } // ......可以添加其他要专递的登录用户相关的信息 public abstract ResultObject Validate(); }ApiUserID和ApiUserName这样的字段是不需要客户端传递的，我们会根据登录人信息自动填充。
根据实际中的经验，我们往往会做分页查询，会用到页码和每页条数，所为我们再定义个PageRequestBase:
public abstract class PageRequestBase : UserRequestBase { public int PageIndex { get; set; } public int PageSize { get; set; } }因为.net只能继承单个父类，而且有些分页查询可能需要用户信息，所以我们选择继承UserRequestBase。
当然，还可以根据自己的实际情况抽象出更多的公用类，在这不一一枚举。
响应的设计分为两部分，第一个是实际响应部分，第二个会把响应包装一下，加上code和msg，用于表示调用状态和错误信息（好老的方法了，大家都懂）。
响应接口IResponse里什么也没有，就是一个标记接口，不过我们也可以抽象出来两个常用的公用类用于响应列表和分页数据：
public class ListResponseBase<T> : IResponse { public List<T> List { get; set; } } public class PageResponseBase<T>: ListResponseBase<T> { /// <summary> /// 页码数 /// </summary> public int PageIndex { get; set; } /// <summary> /// 总条数 /// </summary> public long TotalCount { get; set; } /// <summary> /// 每页条数 /// </summary> public int PageSize { get; set; } /// <summary> /// 总页数 /// </summary> public long PageCount { get; set; } }