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风格的一些阻碍不匹配问题。