关于RESTful API接口规范，MVC,WebApi，WebService的一些自我想法

现在WebApi这么流行，ModelAndView模式的使用应该是会越来越少
其实视具体项目而定，MVC也还有存在的价值，虽然现在主流的是webapi，WebApi的主要目的是前后端分离，
小型项目，单体应用开发效率MVC还是比较高的。

MVC和WebApi主要区别：

1,MVC是建站的一种框架，倾向于返回用户的页面请求

2,WebApi倾向于返回用户数据请求

3,MVC直接继承System.Web.Mvc.Controller

4,而webapi继承的是System.Web.Http.ApiController

关于RESTful API接口规范

RESTful首次出现在 2000 年 Roy Fielding 的博士论文中，Roy Fielding是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。但是为什么目前各大平台API为什么不使用RESTful的风格来进行开发呢，比如：URL命名格式，只有post get 并没有put delete ，更加没有用到HttpStatusCode ，他们是出于什么目的没有遵循这样的面向资源的开发和设计模型？
我想主要原因有如下：
1，因为支持那些行为能带来的好处显然不及要付出的代价
2，开发效率低【不适应于自动化处理】
3，运行效率低【需要比较复杂的字符串匹配模式】
4，环境适应性差【不适应参数复杂的情况】
5，如果不是有客户硬性需求，那完全就是画蛇添足，为了这种鸡肋的风格又何必呢？

其实个人认为所谓的RESTful架构的核心规范与约束就是为了实现统一接口

那基于WebApi的HTTP接口与基于soap协议的WebService又有什么大的区别呢
基于SOAP协议的WebService的主要优点如下：
1.发布的时候直接提供一个请求地址就行了，其它的客户可自行搞定
2.接口中实现的方法和要求参数一目了然
3.不用担心大小写问题
4.不用担心中文urlencode问题
5.代码中不用多次声明认证(账号,密码)参数，可持久化，不像HTTP接口无连接方式。
6.传递参数可以为数组，对象等.
7.webapi类似于cs架构，需要同时开发客户端API和服务器端程序, 而WebService则类似于bs架构，只需要开发服务器端，不需要开发客户端，客户端只要遵循soap协议，就可以调用.

WebService相对于WebApi的缺点如下：
1，由于要进行xml解析，速度可能会有所降低。
2，编写WebService比编写HTTP接口复杂很多，比如WEBService常用的框架Apache Axis，CXF，都是体量特别庞大，各种引用需求包众多让人头大。比较轻量的算是sun JAX-WS最简单、方便，JWS直接使用JWS API 实现，不借助任何webservice框架,可以轻松实现返回的数据是用XML还是JSON，首选！
综合来说：即使现在webapi满天飞，简单又高效灵活，但是个人认为在同一套内部系统中如果跨开发工具多种语言协同开发使用，最佳的方式还是WebService。用HTTP接口麻烦啰嗦。因为请求调用频率太高且繁琐，但是如果是在同一开发平台中基于web架构的客户端或者是多客户端，PC,WEB,APP共存环境，要实现与后台前后端分离。WEBAPI首选！毕竟：WebApi的出现主要目的就是实现前后端分离！