This project is read-only.

How well does WebAPI co-exist with standard WCF4 APIs?

Topics: Web Api
Nov 17, 2011 at 10:29 AM
Edited Nov 17, 2011 at 10:37 AM

Just wondering if its possible to leverage standard WCF4 stuff with WebAPIs. For instance:

1) If I re-configured default webHttp behaviour in web.config, would that apply to my service that uses WebAPI ?

2) Am assuming routing definitions (route table, filters, backuplists, multi-cast routing etc.) would not work when specified in the config - in which case, is there any alternate way of providing fault tolerance?

3) Would protocol bridging work?

4) Would I be able to configure ServiceBehaviours - specific ServiceAuthorizationManager/Authorization policies for my services?

5) How do I enable the "/help" feature on my service - currently when I type service/help, I get an "endpoint not found error"

[Edit - Priya] - I've discovered we can do this by setting "EnableHelpPage" property on the HttpConfiguration instance we pass to routes.

Just a little confused about when to use WebAPI as opposed to standard WCF4 APIs...and whether I lose some WCF4 features when using WebAPI (I'm guessing I don't but still want to confirm)




Nov 17, 2011 at 3:33 PM
Edited Nov 17, 2011 at 3:34 PM

Hi Priya, long time no tweet :-) I'll answer the ones i can.

1. No

2. I'll let Dan weigh in here.

3. Don't think so.

4. You can configure service behaviors, but they cannot rely on the traditional WCF message. They can configure the service description. Message in web api is specific for Http in web api and so if you access properties and such it will not work.

5. Create an instance of HttpConfiguration or WebApiConfiguration. That class exposes a property for enabling help page. Then pass the config either to MapServiceRoute/or using SetDefaultHttpConfiguration, or set it on an HttpServiceHost if you are creating one yourself. You can also create a derived HttpServiceHostFactory and set config in the constructor. (looks like you figured this out)

You will lose some WCF 4 features for example:

  • WebOperationContext won't work properly, in 4.0 though it will in 4.5
  • If you use Http specific constructs in your web apis like HttpRequestMessage<T> / HttpResponseMessage<T> those apis won't work with other bindings.
  • Operation handlers and message handlers won't work on your non web api services. Message handlers will work in web api 4.5.
  • Behaviors that rely on working directly with Message will not work (as I mentioned).
  • Formatters won't work across bindings.
  • Services that rely on dependencies supplied by an IoC won't work unless you create a custom instance provider or use an IoC that supports integration with WCF.

Supporting services that work across bindings was an explicit non-goal with web api. The goal was to offer something specific and proper for HTTP services. There are ways to design contracts such that they can work across bindings such as splitting out all your http concerns using message and operation handlers. That requires more work, but it does allow you greater reause.

Hope this helps


Nov 18, 2011 at 12:48 PM
Edited Nov 18, 2011 at 12:52 PM

Hi Glenn,

Yup, been off Twitter for some time. Gearing up for some major WCF/WebAPI action, so maybe my tweets will be centered around that soon!

Thanks a ton for the elaborate explanation  - gives me a better understanding of WebAPI. Not deterred from using it for sure - will just need to use it wisely ;-) 

Totally understand that support across bindings is a non-goal. Would love to see some of the WCF features like fault tolerance/error handling via routing in the WebAPI. Btw, the default test client stuff really rocks - its going to make tons of QA folks very,very happy!! :)

Btw, didn't entirely understand the statement below - could you point to an example or any other documentation that could help?

"There are ways to design contracts such that they can work across bindings such as splitting out all your http concerns using message and operation handlers. "





Nov 19, 2011 at 12:39 AM

The WCF Routing Service is really a SOAP intermediary. Web API is all about HTTP as your application protocol (not SOAP), so you would instead want to use an HTTP intermediary for your routing needs. For example, you might try ARR.

Daniel Roth

Nov 19, 2011 at 10:08 AM

Makes perfect sense! Thanks Daniel...