I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
But perhaps my question boils down to the following:
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
- If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
- If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
- If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
- If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With