WCF Web API和ASP.NET Web API之間有什么區別

Question

我以前使用WCF WebAPI做了一些工作，並且非常喜歡它的很多功能，我現在只是玩ASP.NET Web API，它看起來完全不同（IE完全從WCF中刪除）。

有誰知道ASP.NET 4 Web API中包含WCF WebAPI的哪些功能？

Answer 1

我已經做了一些閱讀，並在MS上發現了幾頁：

http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :

WCF Web API抽象映射到ASP.NET Web API大致如下

WCF Web API - > ASP.NET Web API

• 服務 - > Web API控制器
• 操作 - >動作
• 服務合同 - >不適用
• 端點 - >不適用
• URI模板 - > ASP.NET路由
• 消息處理程序 - >相同
• 格式化程序 - >相同
• 操作處理程序 - >過濾器，模型粘合劑

和http://wcf.codeplex.com/discussions/319671

集成堆棧支持以下功能：

• 現代HTTP編程模型
• 完全支持ASP.NET路由
• 內容協商和自定義格式化程序
• 模型綁定和驗證
• 過濾器
• 查詢構成
• 易於單元測試
• 通過DependencyResolver改進控制反轉（IoC）
• 基於代碼的配置
• 自主機

Answer 2

從我所學到的，微軟在這里做了一點點混淆。

我假設您知道WCF是什么，這個基於XML的大型框架允許用戶使用各種技術（從SOAP到REST到MSMQ等）構建分布式服務。

這對我來說很難（至少對我而言）並且需要大量的引導來使它工作，最終他們意識到這一點並開始為簡單的http服務提供一些默認配置（任何人都可以使用WCF REST入門套件？）。 ASP.NET MVC正在獲得動力，它提供的一些功能（例如自動參數匹配）開始出現在WCF中。

現在情況就是這樣：

公告：WCF Web API現在是ASP.NET Web API！ ASP.NET Web API隨ASP.NET MVC 4 Beta一起發布。 到2012年底，WCF Web API和WCF對此站點上jQuery內容的支持將被刪除。

http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api

那是更好的imho。

我很確定應該可以在WCF之上托管asp.net mvc4 webapi（如果你需要的話），但我找不到可以證明我正確（或錯誤）的文檔。

更新 （不能作為評論）：等等，“將通信技術的子集從庫/框架移動到另一個”和“替換WCF”之間存在巨大差異。 我個人認為WCF是為某種通信概念設計的，它有一個相當酷的設計，但分布式計算有點轉向新的（和更簡單的）解決方案（看看功能豐富的SOAP與精益靈活的REST，雖然很多人仍然以RPC方式使用REST），我認為這種編程模式比WCF更適合MVC架構。 努力設計了一些在WCF之上構建/使用Web服務的簡單方法，但他們最終發現它不是正確的解決方案。

更不用說許多開發人員現在使用ASP.NET MVC並希望為他們的Web應用程序做休息Web服務，弄亂WCF對於這些事情來說往往有些過分，而且我在自己的皮膚上經歷過這種情況。

我認為路由機制很棒，也是正確的方法，如果仔細觀察，它們會在WCF中包含部分內容（具有不同的名稱和類型，但模式在那里）。 所以，是的，我認為如果MS不解雇WCF的那部分我們應該這樣做。 要嚴格回答，不，我認為你永遠不會在asp.net mvc *中找到WebGet / WebInvoke，它只是不適合。

是的自主機可能是現在ASP.NET MVC4中包含的WCF的唯一位置。

Answer 3

看起來WCF本身在某種程度上正在死亡，或者至少變得不那么重要，因為它應該是它的功能集中的開發工作量也少得多。 WCF本身的新功能更具美感。

WCF被設計為用於進程間通信的獨立於傳輸/協議的方式。 即使這個想法是獨立的抽象，它主要建立在SOAP堆棧之上。 當WCF 3.5為REST提供支持時，它主要被黑客入侵，因為REST完全是關於傳輸依賴性的。 使用傳輸獨立API來支持通過直接使用傳輸功能完成的進程間通信顯得不方便。 結果MS首次發布了從未到達RTM的WCF Rest API Starter Kit，但它是后來包含在WCF 4中的功能的預覽，最后是.NET 4.5或WCF Web API。 因為REST依賴於傳輸並且目前僅用於HTTP（即使理論上可以使用其他傳輸協議），API也被移動到更適合HTTP處理的.NET部分 - 當前非常流行的ASP.NET MVC。

Answer 4

WCF Web API由ASP.NET Web API取代，后者從WCF Web API獲取功能並將它們與ASPNet MVC中的功能合並。 ASP.NET Web API是用於構建和使用HTTP服務的新（02/2012）框架，以及用於構建RESTful服務的平台。

雖然不在最初的問題中，但值得注意的是WCF仍然存在並且當您擁有必須支持的現有SOAP（WS- *）服務但其希望添加REST以接觸更多客戶端時，其REST支持仍然有用。

參考

1. CodePlex：WCF Web API現在是ASP.NET Web API
2. CodePlex：Daniel Roth關於WCF的未來
3. Chanel9：Dan Roth關於新的ASP.NET Web API

Answer 5

本MSDN頁面上的以下摘錄很好地總結了這一難題。

使用WCF創建可通過各種傳輸訪問的可靠，安全的Web服務。 使用ASP.NET Web API創建可從各種客戶端訪問的基於HTTP的服務。 如果要創建和設計新的REST樣式的服務，請使用ASP.NET Web API。 盡管WCF為編寫REST樣式的服務提供了一些支持，但ASP.NET Web API中對REST的支持更加完善，所有未來的REST功能都將在ASP.NET Web API中進行。 如果您有現有的WCF服務並且希望公開其他REST端點，請使用WCF和WebHttpBinding。

Answer 6

這是關於Web服務，WCF和Web API的好文章http://goo.gl/T29A5B

網絡服務

• 基於SOAP並返回XML數據
• 僅支持HTTP協議。 它僅支持HTTP協議。
• 由能夠理解xml SOAP服務的客戶端消費。
• 可以在IIS上托管。 它只能在IIS上托管。
• 易於學習和理解。

WCF

• 基於SOAP並返回XML數據。 與JSON及其在網絡上的開銷相比，SOAP比較重要。
• 增強版Web服務通過配置支持多種協議，如TCP，HTTP，HTTPS，命名管道，MSMQ。
• 當客戶端和服務器都有.Net時更可靠。
• 它的實現和配置很復雜
• 由能夠理解xml SOAP服務的客戶端消費。
• 自托管，IIS和使用Windows服務。

Web API（Web API 2.0）

• 專為在.Net Framework上構建HTTP Restful Services而設計。
• Web API易於閱讀並且像JSON一樣方便。
• 支持HTTP的所有功能，如URls，請求/響應，標頭，緩存和版本控制。
• Web API支持許多HTTP動詞，如GET，POST，PUT，DELETE等。
• Web API是無狀態的。
• Web API支持MVC功能（控制器，操作結果，路由，過濾器，模型綁定器，IOC容器或依賴注入）
• Web API可以自托管，在應用程序和IIS上托管。
• OWIN（Open Web Interface for .NET）用於自托管。

Answer 7

ASP.net web api是輕量級的，內置REST支持。 它更適合移動應用程序.WCF臃腫，有更多選項。 這取決於系統的復雜性來選擇其中之一。