WebApi&MVC对比
使用上区分，mvc主要用于建站，web api主要用于构建http服务，当然你非要用mvc来构建Uri式的Api也行，不过显然是没有这个必要的，一个不恰当的比喻就像是你也可以玩破解版的单机游戏，也可以通过平台进行联机，但是始终不如steam上来得爽是吧。
自身实现上区分的话，两种框架主要是在Asp .Net的基础上进行改造，主要是对HttpModule和HttpHandler做了扩展，实现方法是不一样的，比如说前者更像是在一层上建了第二层，引伸出更强大的路由机制，实现了诸如MvcHandler和ControllerFactory这种消息处理和后台控制器方法选择机制，Web Api除了扩展了前者以外，另外写出了一套独立的，独立于Asp .Net的消息处理管道，就像是借鉴原来房子的模型，重新设计出了另外一套别墅。这也很好地解释了为什么Web Api可以寄宿在不同的宿主上（寄宿的本质就是利用一个具体的应用程序为Web Api提供一个运行的环境，并解决请求的接收和响应的回复），如Web Host，Self Host方式，这和WCF是相似的。而MVC只能寄宿于IIS上（不考虑.net core），就像Webform的寄宿方式。何况它们两者虽然都有Controller和Action，但是请求的实现和响应的回复机制也是不同的，比如说Web Api处理消息有两个核心类是HttpRequestMessage和HttpResponseMessage。这两种框架最多只能说是模式上类似，实现上还是有很大差别的。不过两者都是Asp .Net的组成成员，图上表现得很清楚了。
自身实现上区分的话，两种框架主要是在Asp .Net的基础上进行改造，主要是对HttpModule和HttpHandler做了扩展，实现方法是不一样的，比如说前者更像是在一层上建了第二层，引伸出更强大的路由机制，实现了诸如MvcHandler和ControllerFactory这种消息处理和后台控制器方法选择机制，Web Api除了扩展了前者以外，另外写出了一套独立的，独立于Asp .Net的消息处理管道，就像是借鉴原来房子的模型，重新设计出了另外一套别墅。这也很好地解释了为什么Web Api可以寄宿在不同的宿主上（寄宿的本质就是利用一个具体的应用程序为Web Api提供一个运行的环境，并解决请求的接收和响应的回复），如Web Host，Self Host方式，这和WCF是相似的。而MVC只能寄宿于IIS上（不考虑.net core），就像Webform的寄宿方式。何况它们两者虽然都有Controller和Action，但是请求的实现和响应的回复机制也是不同的，比如说Web Api处理消息有两个核心类是HttpRequestMessage和HttpResponseMessage。这两种框架最多只能说是模式上类似，实现上还是有很大差别的。不过两者都是Asp .Net的组成成员，图上表现得很清楚了。
首先，两者的主要解决的问题不同！
MVC的主要使用场景在于Web站点的开发，他在后端实现了一套完整的MVC开发框架，能提供方便的页面开发，默认使用Razor视图引擎，提供了后端html构造，用户可以方便地开发出带页面的站点。
而WebAPI主演提供了一套RestfulAPI的开发框架，提供了较为完整的http语义支持，主要用来做开放API，更抽象，更不注重View的生成。
从实现的角度看，虽然他俩捆绑在一起，但是两者处理管线还是不同的。
如果你对http有较为深入理解后，你就会发现，其实他俩的界限没那么明显，那么你也许会觉得mvc做的事webAPI都能做，因为他更抽象，有时候你又不想把两者的界限搞得那么清晰
MVC的主要使用场景在于Web站点的开发，他在后端实现了一套完整的MVC开发框架，能提供方便的页面开发，默认使用Razor视图引擎，提供了后端html构造，用户可以方便地开发出带页面的站点。
而WebAPI主演提供了一套RestfulAPI的开发框架，提供了较为完整的http语义支持，主要用来做开放API，更抽象，更不注重View的生成。
从实现的角度看，虽然他俩捆绑在一起，但是两者处理管线还是不同的。
如果你对http有较为深入理解后，你就会发现，其实他俩的界限没那么明显，那么你也许会觉得mvc做的事webAPI都能做，因为他更抽象，有时候你又不想把两者的界限搞得那么清晰
