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 elementsIf 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?
Should I use both WCF and ASP.NET Web API
web services;rest;wcf;soap
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)