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可以跨域就叫「不安全」，那他應該弄明白怎麼樣才能跨域。