公开 REST/HTTP 和命名管道端点的 WCF 服务
我正在构建一套 .Net 4.0 WCF 服务，该服务将由基于 ASP.NET MVC3 浏览器的应用程序访问，并且我正在寻找有关以下方法的评论/建议/示例。这是我们的场景：
由于权限和配置的原因，浏览器应用程序页面的初始渲染需要大量的服务器端逻辑。浏览器应用程序的服务器端代码需要访问 WCF 服务才能正确呈现初始 HTML/JavaScript。我们宁愿在服务器端进行初始渲染，也不愿推出控制框架并让浏览器发出 AJAX 调用以获取初始状态。
一旦 HTML 返回到客户端，客户端与应用程序的交互将启动对 WCF 服务的 AJAX 调用 - 通常是在服务器端呈现期间访问的相同服务。
我们还希望将 WCF 服务的某些方法作为 RESTful 接口公开给第三方。
意识到我们还可以使用 ASP.Net MVC 来公开 RESTful 服务，因此我们最好使用 WCF 服务组件来提供未来的可扩展性 - 我们最终可能希望在服务器场中独立运行业务服务。
因为同一 IIS 实例将托管网站和 WCF 服务，对于 WCF 服务调用的服务器端代码，我认为我们使用命名管道传输和二进制编码获得了一些性能，但因为我们将使用 AJAX 和支持互联网的 API，我们还必须公开 RESTful 服务。
我看过很多 WCF .Net 4.0 RESTful 服务的示例，但没有一个使用具有不同传输的多个端点，并且使用 JSON over HTTP 的 .Net 3.5 示例似乎不能很好地转换到 .Net 4.0 空间。
想法/指导？提前致谢。
I'm in the process of building a suite of .Net 4.0 WCF services that will be accessed by an ASP.NET MVC3 browser based application and I'm looking for comments/suggestions/examples on the following approach. Here's our scenario:
Initial rendering of the browser app pages requires significant server-side logic due to permissions and configuration. The server-side code of the browser app needs to access the WCF services to properly render the initial HTML/JavaScript. We'd rather take the initial rendering hit server-side than push out a control skeleton and have the browser issue AJAX calls for initial state.
Once the HTML is returned to the client, client interactions with the app will initiate AJAX calls to the WCF services - often to the same services that were accessed during server-side rendering.
We also wish expose certain methods of the WCF services as a RESTful interface to third parties.
Realizing we could also use ASP.Net MVC to expose a RESTful service, it is preferred that we use a WCF servies component to provide for future scalability - we may eventually want to run the business services independently in a server farm.
Because the same instance of IIS will be hosting both the web site and the WCF service, for the server-side code to WCF service calls, I'm thinking we gain some performance using Named Pipes transport and binary encoding, but because we'll be using AJAX and an internet enabled API, we also have to expose a RESTful service.
I've seem plenty of examples for WCF .Net 4.0 RESTful services, but none that use multiple endpoints with different transports, and the .Net 3.5 examples that use JSON over HTTP don't seem to translate well to the .Net 4.0 space.
Thoughts/guidance? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不确定您是否真的想在项目中使用命名管道和二进制协议。这是相当古老的技术，而且还没有真正适合网络。通过二进制编码获得的性能可能抵不上可扩展性的损失。当普通无状态 HTTP RESTful API 出现性能问题时，您可以在其前面放置一个负载均衡器，并将其扩展到多个设备上。我不确定是否可以对可通过命名管道访问的服务进行负载平衡。
我尝试使用 WCF 来实现 json REST API。理论上一切看起来都不错，但WCF是一门大炮，不值得用它来射苍蝇。无论如何，在使用 WCF 一段时间后（并且在实现基于 cookie 的身份验证时陷入困境），我最终得到了一个非常简单的解决方案，我在这里描述 http://blog.lome.pl/mvc/implementing-asp-net-mvc-rest-api/
I'm not sure if you really want to use named pipes and binary protocols in your project. It's quite old technology, and not really web-ready. The performance you can gain with binary encoding might not be worth loss of scalability. When having a performance issues with an ordinary stateless HTTP RESTful API, you can put a load balancer in front of it and scale it on multiple boxes. I'm not sure if its even possible to load-balance a service accessible through a named pipes.
I tried myself using WCF for implementing json REST API. Everything looks nice in theory, but WCF is a big cannon, it's not worth to use it to shoot a fly. Anyway after playing with WCF for a while (and getting stuck when implementing cookie based authentication) I ended up with a quite simple solution i described here http://blog.lome.pl/mvc/implementing-asp-net-mvc-rest-api/
老实说，我认为您最大的问题是设计 API 使其在 REST 和 RPC 领域都能很好工作。这是两个截然不同的世界，设计“自然”API 来满足这两个世界通常对其中一个或另一个都有害。
从技术上讲，如果您使用仅由简单的内在 .NET 类型（字符串、整数、Guid 等）组成的参数来处理所有内容，那么您将“没问题”。但是，如果您想使用自己的复杂类型，那么除非您进行大量工作以将 REST 请求映射到这些类型，否则 REST 将开始崩溃，因为它不是开箱即用的。因此，REST 可能会迫使您改变 API 设计，使其不再像 RPC 那样，从 REST 的角度来看，这很好，但是通过 RPC 访问它的人在查看它时可能会想知道您在吸烟。
我应该补充一点，新的 WCF HTTP API 位可以为复杂类型编写映射<比现在容易得多。如果您想继续追求这一目标，您可能想尝试一下这些，但它们还不是 RTM。您肯定仍然会遇到 RPC 与 REST 风格的一些阻抗不匹配问题。
Honestly, I think your biggest problem will be in designing your APIs to work nicely both in the world of REST and RPC. It's two very different worlds and designing "natural" APIs to appease both is often detrimental to one or the other.
Technically speaking, if you use parameters only made up of the simple intrinsic .NET types (string, int, Guid, etc.) for everything you will be "ok". However, if you want to use your own complex types REST will start to fall apart on you unless you do a lot of plumbing to map REST requests to those types because it is not provided out of the box. So REST will potentially force you to change your API design to be less RPC'ish, which is great from the REST perspective, but the people who are accessing it via RPC might wonder what you were smoking when they look at it.
I should add that the new WCF HTTP API bits make writing mappings for complex types much easier than it is today. You may want to experiment with those if this is something you want to continue to pursue, but they are not RTM yet. You will definitely still bump up against some impedence mismatch issues with RPC vs. REST style.