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?
4
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)
1
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
servicestacktag, 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.
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.
2