1
votes

I have a widely distributed legacy web forms asp.net application with some WCF services exposed as webHttp endpoints. I'm in the process of reengineering the application to introduce functionality that is best implemented as MVC and web API controllers.

Since introducing MVC and web API to the application none of the webHTTP endpoints are accessible. For example Printing.svc implemented an interface with:

[ServiceContract]
public interface IPrinting
{
    [WebGet(UriTemplate = "Printers")]
    List<string> Printers(string profile);
}

I can successfully navigate to printing.svc and printing.svc/metadata, however, the printing.svc/help or printing.svc/Printers all return a 400 error (blank page). All the Web API and MVC routes work, and the wsdl for the soap bindings also work. Just not the "REST" WCF endpoints.

I have already added ignore values for the .svc routes:

routes.IgnoreRoute("{resource}.svc");
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");

Still no dice. I have reproduced all this functionality in Web API, but would have liked to keep the old services active for legacy deployments.

So, can these two technologies coexist?

Are there any work arounds, or is it time to drop the "REST" WCF endpoints and move on?

EDIT

The solution: As suggested, I disabled routing in Web API and MVC, and ended up having to change from:

<endpointBehaviors>
  <behavior name="restBehaviour">
    <webHttp />
  </behavior>
  <behavior name="wsBehaviour" />
</endpointBehaviors>

to:

<endpointBehaviors>
  <behavior name=""><!-- Added -->
    <webHttp />
  </behavior>
  <behavior name="restBehaviour">
    <webHttp />
  </behavior>
  <behavior name="wsBehaviour" />
</endpointBehaviors>

even though my service is:

<service name="K3.Reports.Web.Printing">
  <endpoint address="" binding="webHttpBinding" contract="K3.Reports.Contracts.IPrinting" behaviorConfiguration="restBehaviour" />
</service>
2

2 Answers

2
votes

Those technologies can coexist as far as I can tell. Our application is a WebForms application that includes both some WCF "rest" end points for RSS feeds as well as a REST WebApi.

It could therefore be that the default API route is taking over the WCF ones in some cases. Did you try to deactivate the default route?

If yes you may want to add more details in your question as how your routes are configured and versions you are running.

0
votes

This is a very good question. Most questions pit the two technologies against each other. In WCF I am using transactions, fault exception handling and other technologies built into WCF. I enjoy using Web API 2 but have done so from the client (web browser) to the IIS server hosting that API. Our company is committed to using services behind the firewall which is compatible with Web API 2 and may even be easier to implement. My concern though is, how much of what I lose when switching from WCF to Web API 2 will I need to "role my own". Examples I have read on distributed transaction support for Web API 2 refer to using on configuring DTC (ugh). Can WCF and Web API 2 be considered as transport mechanisms between a proxy and the remote service implementation (stub)? If so, could I use Web API 2 to initiate the service request, pass in the data, and use WCF technologies? Too many ppl consider Web API as an evolution of WCF and that WCF is old and/or dead. Web API doesn't seem to fit the SOA environment we are required to use, so the best of both worlds would be nice when developing front-to-back web based solutions in SOA environments.