API Design – Using Both WCF and ASP.NET Web API

api-designrestwcfweb servicesweb-api

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?

Best Answer

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)

Related Topic