WCF service exposing REST/HTTP and Named Pipes endpoints

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.

---

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/

---

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.