Webservice WCF WebApi

注明:改编加组合

在.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直接传输数据而无须预先定义,这两个都是弱类型的语言:
    • 好处,再复杂的类型(只要不是循环引用)都轻松的搞定
    • 不好不坏,基础类型都有,通用性十足(WSDL也有,而且只需要做一次)
    • 坏处,没有动态语言功底的环境,每次都需要解析比较吃力(WS有了WSDL,这种事情只需要做一次)
  3. 无法获得消息结构的定义。正如2中描述的那样,如果描述一个数据那么复杂,又何必为了它建立一个公开接口定义?相应的,如果描述很容易,也没有必要去事先定义。
  4. 无法定义多个操作。。。对于调用API的人来说没有任何作用。
  5. 无法定义多个站口/通讯协议。这也是个赘饰。

少了服务定义又会怎样?

  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能够跨域就叫“不安全”,那他应该弄明白怎么样才能跨域。

上一篇:MySQL 批量插入值


下一篇:微信公众平台如何与Web App结合?