注明：改编加组合

在.net平台下，有大量的技术让你创建一个HTTP服务，像Web Service，WCF，现在又出了Web API。在.net平台下，你有很多的选择来构建一个HTTP Services。我分享一下我对Web Service、WCF以及Web API的看法。

　　Web Service

　　1、它是基于SOAP协议的，数据格式是XML

　　2、只支持HTTP协议

　　3、它不是开源的，但可以被任意一个了解XML的人使用

　　4、它只能部署在IIS上

　　WCF

　　1、这个也是基于SOAP的，数据格式是XML

　　2、这个是Web Service（ASMX）的进化版，可以支持各种各样的协议，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.

　　3、WCF的主要问题是，它配置起来特别的繁琐

　　4、它不是开源的，但可以被任意一个了解XML的人使用

　　5、它可以部署应用程序中或者IIS上或者Windows服务中

　　WCF Rest

　　1、想使用WCF Rest service，你必须在WCF中使用webHttpBindings

　　2、它分别用[WebGet]和[WebInvoke]属性，实现了HTTP的GET和POST动词

　　3、要想使用其他的HTTP动词，你需要在IIS中做一些配置，使.svc文件可以接受这些动词的请求

　　4、使用WebGet通过参数传输数据，也需要配置。而且必须指定UriTemplate

　　5、它支持XML、JSON以及ATOM这些数据格式

　　Web API

　　1、这是一个简单的构建HTTP服务的新框架

　　2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

　　3、不像WCF REST Service.它可以使用HTTP的全部特点（比如URIs、request/response头，缓存，版本控制，多种内容格式）

　　4、它也支持MVC的特征，像路由、控制器、action、filter、模型绑定、控制反转（IOC）或依赖注入（DI），单元测试。这些可以使程序更简单、更健壮

　　5、它可以部署在应用程序和IIS上

　　6、这是一个轻量级的框架，并且对限制带宽的设备，比如智能手机等支持的很好

　　7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

　　WCF和WEB API我该选择哪个？

　　1、当你想创建一个支持消息、消息队列、双工通信的服务时，你应该选择WCF

　　2、当你想创建一个服务，可以用更快速的传输通道时，像TCP、Named Pipes或者甚至是UDP（在WCF4.5中）,在其他传输通道不可用的时候也可以支持HTTP。

　　3、当你想创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时（比如URIs、request/response头，缓存，版本控制，多种内容格式），你应该选择Web API

　　4、当你想让你的服务用于浏览器、手机、iPhone和平板电脑时，你应该选择Web API

　　原文：http://www.dotnet-tricks.com/Tutorial/webapi/JI2X050413-Difference-between-WCF-and-Web-API-and-WCF-REST-and-Web-Service.html

Web API = Web Service - 服务定义，换言之 Web API + 服务定义 = Web Service。

少了服务定义会怎样？

1. 无法发现服务，从而也无法知晓服务的变更和删除。但，这样又如何？服务发现本来就是UDDI而非WSDL做的事情。
2. 无法获得数据类型的定义。Web API在这方面使用XML或者json直接传输数据而无须预先定义，这两个都是弱类型的语言：
3. • 好处，再复杂的类型(只要不是循环引用)都轻松的搞定
   • 不好不坏，基础类型都有，通用性十足（WSDL也有，而且只需要做一次）
   • 坏处，没有动态语言功底的环境，每次都需要解析比较吃力（WS有了WSDL，这种事情只需要做一次）
4. 无法获得消息结构的定义。正如2中描述的那样，如果描述一个数据那么复杂，又何必为了它建立一个公开接口定义？相应的，如果描述很容易，也没有必要去事先定义。
5. 无法定义多个操作。。。对于调用API的人来说没有任何作用。
6. 无法定义多个站口/通讯协议。这也是个赘饰。

少了服务定义又会怎样？

1. 仍然需要一个服务的源来暴露服务。作为一个服务提供商，这是理所当然要做的事情。
2. 数据类型的定义。只要不出现循环引用，一切都简单到不能更简单。
3. 服务接口的定义。也许我们无法提供在线的代码框架生成，但我们可以提供手册+现成的接口调用代码。

当然具体到WS的代表SOAP与WebAPI的代表json。PK不会发生在Soap->Http Header VS Http Header(结果一样)，就只有Soap Body->Http Body->XML vs Http Body->json了。这两者没什么可说的，json基本上是完胜。

所以，一个通常的服务提供商，json形式的Web API加上统一的源管理，胜过soap+http的Web Service。不要扯什么安全性，大家都是http基础；如果认为json能够跨域就叫“不安全”，那他应该弄明白怎么样才能跨域。