Webservice WCF WebApi

注明：改编加组合

 

在.net平台下，有大量的技术让你建立一个HTTP服务，像Web Service，WCF，如今又出了Web API。在.net平台下，你有不少的选择来构建一个HTTP Services。我分享一下我对Web Service、WCF以及Web API的见解。

　　Web Service

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

　　二、只支持HTTP协议

　　三、它不是开源的，但能够被任意一个了解XML的人使用

　　四、它只能部署在IIS上

 

　　WCF

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

　　二、这个是Web Service（ASMX）的进化版，能够支持各类各样的协议，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.

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

　　四、它不是开源的，但能够被任意一个了解XML的人使用

　　五、它能够部署应用程序中或者IIS上或者Windows服务中

 

　　WCF Rest

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

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

　　三、要想使用其余的HTTP动词，你须要在IIS中作一些配置，使.svc文件能够接受这些动词的请求

　　四、使用WebGet经过参数传输数据，也须要配置。并且必须指定UriTemplate

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

 

　　Web API

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

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

　　三、不像WCF REST Service.它可使用HTTP的所有特色（好比URIs、request/response头，缓存，版本控制，多种内容格式）

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

　　五、它能够部署在应用程序和IIS上

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

　　七、Response能够被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

　　

　　WCF和WEB API我该选择哪一个？

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

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

　　三、当你想建立一个基于HTTP的面向资源的服务而且可使用HTTP的所有特征时（好比URIs、request/response头，缓存，版本控制，多种内容格式），你应该选择Web API

　　四、当你想让你的服务用于浏览器、手机、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可以跨域就叫“不安全”，那他应该弄明白怎么样才能跨域。