WCF服務暴露REST/HTTP和命名管道端點

Question

我在建立了一套將通過ASP.NET MVC3基於瀏覽器的應用程序訪問.NET 4.0 WCF服務的過程中，我在找的意見/關於以下方法的建議/例子。下面是我們的情景：

瀏覽應用程序頁面的初始渲染需要適當權限和配置顯著服務器端邏輯。瀏覽器應用程序的服務器端代碼需要訪問WCF服務以正確呈現最初的HTML/JavaScript。我們寧願採用最初的渲染命中服務器端，而不是推出一個控制框架，讓瀏覽器發出AJAX調用初始狀態。

一旦HTML被返回給客戶端，在應用程序將啓動AJAX調用WCF的服務客戶交互 - 經常到服務器端渲染期間訪問相同的服務。

我們也希望暴露WCF服務的某些方法作爲一個RESTful接口給第三方。

意識到我們也可以使用ASP.Net MVC公開一個RESTful服務，我們最好使用WCF servies組件來提供未來的可伸縮性 - 我們最終可能希望在服務器場中獨立運行這些業務服務。

因爲IIS的同一個實例將承載網站和WCF服務，對於服務器端代碼來WCF服務調用，我認爲我們使用命名管道傳輸和二進制編碼獲得了一些性能，但因爲我們將使用AJAX和支持互聯網的API，所以我們還必須公開一個RESTful服務。

我看起來很多WCF .Net 4.0 RESTful服務的例子，但沒有一個使用多個端點和不同的傳輸，而使用JSON over HTTP的.Net 3.5例子似乎沒有很好地轉化爲。 Net 4.0空間。

想法/指導？提前致謝。

Answer 1

我不知道，如果你真的想使用命名管道和二進制協議在您的項目。這是相當古老的技術，並沒有真正的網絡準備。使用二進制編碼可以獲得的性能可能不值得失去可伸縮性。如果使用普通的無狀態HTTP RESTful API時出現性能問題，可以將負載均衡器放在它的前面並在多個盒子上進行縮放。我不確定是否有可能通過命名管道來訪問可以訪問的服務。

我試着自己使用WCF實現JSON REST API。理論上一切看起來不錯，但WCF是一個大炮，用它來拍攝蒼蠅是不值得的。與WCF玩了一會兒（和實施基於cookie認證時被卡住）後，無論如何，我結束了一個非常簡單的解決方案老實說，我這裏所描述http://blog.lome.pl/mvc/implementing-asp-net-mvc-rest-api/

Answer 2

，我覺得你最大的問題將是在設計你的API來工作很好的都在REST和RPC的世界裏。這是兩個截然不同的世界，設計「自然」的API來安撫這兩者往往是不利於其中之一。從技術上講，如果你只使用由簡單的內在.NET類型（string，int，Guid等）組成的參數，那麼對於你所有的東西都是「OK」的。但是，如果您想使用自己的複雜類型，REST將開始在您身上分崩離析，除非您做了很多管道工作來將REST請求映射到這些類型，因爲它不是開箱即用提供的。因此，REST可能會迫使您將您的API設計更改爲RPC更少，這從REST的角度來看非常棒，但通過RPC訪問它的人可能會想知道您在看什麼時吸菸。

我應該補充一點，new WCF HTTP API位爲複雜類型編寫映射多比今天更容易。如果這是你想要繼續追求的東西，你可能想要試驗一下，但它們還不是RTM。你肯定會碰到RPC與REST風格的一些阻礙不匹配問題。