Well not quite.
The two really can serve very different purposes.
- WCF is designed so that all of your connectivity and endpoints are abstracted away from the core operations of the service (Although you may need to apply certain attributes to your operation contract)
- All of the connectivity and endpoint data is largely configured through the Web.Config file (and you really should be read up on what your settings do before trying to tweak them)
- WCF therefore allows you to switch out endpoints and connections through the Web.Config file without the need for recompiling (for example, if you wanted to disable SOAP on a SOAP and JSON web service)
That's a lot of power.
So the question is, what if my intention is to only ever create a RESTful webservice and I never need to support other message types (such as SOAP)? Should I be using WCF?
Well, the short answer is that you can, but you'd be using a sledgehammer to crack a nutshell. Another major factor will be the issue that WCF doesn't really let you go all the way with REST very easily:
- All WCF requests for webHttpBindings are steered towards only using GET [WebGet] and POST [WebInvoke]
- Enabling other HTTP verbs can involve configuration of IIS to accept request of that particular verb on .svc files
- Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified
I'm a big fan of the KISS principle. So if you are going to setup a Web Service and don't need SOAP, you should take a good look at the ASP.Net Web API.
But what do the experts say?
Well, Christian Weyer, who basically had a hand in WCF's inception, states in this blog post that the web is going in a new direction, focused around lightweight web based architectures. He is leaning toward using the ASP.Net Web API for these sorts of architectures.
apigee have made a fantastic ebook on Web APIs available to download for free. It's a great read, and got me thinking about web services in more detail.