Should I use both WCF and ASP.NET Web API

Question

We already have a WCF API with basichttpbinding. Some of the calls have complex objects in both the response and request.

We need to add RESTful abilities to the API. at first I tried adding a webHttp endpoint, but I got

At most one body parameter can be serialized without wrapper elements

If I made it Wrapped it wasn't pure as I need it to be.

I got to read this, and this (which states "ASP.NET Web API is the new way to build RESTful service on .NET").

So my question is, should I make 2 APIs(2 different projects)? one for SOAP with WCF and one RESTful with ASP.NET Web API? is there anything wrong architecturally speaking with this approach?

• hanzolo: What type of message formats are you looking for?
• Mithir: What do you mean? Json or XML are fine by me...
• hanzolo: that's what I meant..
• Thraka: There is also WCF Data Services, formerly ADO.NET Data Services: msdn.microsoft.com/library/cc668792.aspx. It implements the OData REST protocol (odata.org).

Answer 1

I was asking myself the same question until I found this WCF and ASP.NET Web API comparison page on MSDN (with my own emphasis below):

Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

IMO, having two APIs (two projects) is not a good approach: you are going to have maintenance problems, and you may confuse or trouble your service consumers / clients.

I would say it depends on your project requirements and client needs. If SOAP is a must, go with @Smokefoot's answer, use WCF and expose SOAP and REST endpoints. If no client wants to use SOAP any more and they want REST, stop the development on the WCF version (web service v1) and go for ASP.NET Web API (web service v2)

• Berin Loritsch: These days there are fewer real arguments for SOAP. Everything that the W3C Web Services architecture provided has a suitable replacement in a REST environment--including service discovery. ASP.NET Web API is going to be easier to write and maintain.

Answer 2

This isn't really a direct answer to your question, but an alternative for you to explore.

In addition to my other answer, you can also check out another .NET web service framework called ServiceStack. Some good points about it:

• Open source.
• Support both SOAP and REST endpoints out of the box.
• Focus on performance, e.g. fastest text serializers in .NET, Redis support.
• Adhere to best practices, e.g. Martin Fowler's EAA, message-based web service.
• Extensive documentation at GitHub Wiki.
• Good support at StackOverflow with the servicestack tag, by the project creator Demis Bellot (aka. mythz).

Notable mentions comparing ServiceStack and ASP.NET Web API:

• ServiceStack vs ASP.Net Web API on StackOverflow.
• ServiceStack versus ASP .NET Web API on LinkedIn.

If you want to know more about ServiceStack, be sure to check out their official site, with codes and documentation at GitHub, and a presentation at slideshare.

Answer 3

The new Web API included in the new ASP.NET MVC is good for adding restful services to pages to enable some AJAX functionalities. It is good if you only want to have a small API or something like that but rest only.

In the moment where you implement REST and SOAP as a bigger API I would allways prefer to use a WCF application. I think this approach is better to maintain and you have all web services located in a central project.

• Mithir: Would you suggest implementing two different contracts? (one for rest and one for soap)
• Smokefoot: I would suggest to implement two different contracts. The good thing about that is that same sharing the same functionality ;-) There are some applications doing this as well, like SharePoint (bad example ;-) )