… since the 2 frameworks are frustratingly similar. Their key features and provided functionality often overlap. So, you had better ask yourself, first things first: what are your development needs? Which is the main purpose that you need your framework to serve, whether it's WCF or Web API? This is THE question!
Is it an internal web service or an external one that you need to develop?
As you can see: it takes just one key question to entail relevant and effective questions one after another.
Questions that will lead you to the answer to your “thorny” dilemma: which framework would be most suitable for my project, WCF or Web API?
May I give you a hand?
Allow me to set the stage and bring the 2 "contestants" forward into the spotlight! Let's see what each one of these 2 rivaling technologies has to offer you and which one's approach and features better matches your project's specific requirements.
What Is WEB API's Offer in Terms of Functionality?
But first, let me try and come up with a so-called “definition” of the ASP.NET Web API's framework:
It's a framework (obviously!) designed to turn building HTTP services, RESTful apps on the .NET framework, into a “breeze”. And here I'm referring to HTTP services reaching to an entire network of clients expecting to be able to access them, nice and easy, on a variety of modern devices.
There! I've just hit the nail right on the head with that ending part of my definition: this framework enables you to build HTTP-based services easily accessible from a whole plethora of mobile devices.
And it's WEB API's main trump card in any “WCF or Web API for mobile” debate.
Using WEB API to build your web service with, you're practically turning the inconvenience of web-based apps' growing more and more ineffective, into an advantage.
By leveraging your APIs — compatible with all devices and browsers — you're making your app's data, your web services highly accessible to multiple devices.
But allow me to highlight some of the possible answers to your “Why Use Web API Instead of WCF?” question:
- it's open source, which makes it the ideal platform for developing RESTful services on top of the .NET framework
- there's no need to get yourself tangled up in additional configuration settings for each and every type of device (and you sure need to knee deep in configuration if it's a WCF Rest service scenario that you choose)
- being HTTP-only, it grants your web services a much wider reach: to all browsers, all mobile devices
- it leverages the entire set of features of HTTP (unlike the WCF REST service): versioning, caching, response/request headers, various content formats
- WEB APIs support a whole variety of media types (via its MediaTypeFormatter): JSON, XML and the list of formats can go on
- it ships with the /NET framework, but thanks to its open-source nature it's available to you via independent download (out-of-band), too
- it has a conveniently lightweight design, just perfect for low-bandwidth devices, one of the significant advantages of Web API over WCF
What About WCF? Which Are Its Most Compelling Features?
Again, let's see what a Windows Communication Foundation framework is before we jump to exposing its tempting features:
It's Microsoft's unidifed programming model that you get to use for developing interoperable, distributed and service-oriented apps.
In a nutshell: it enables you to build one single reliable, secure and transacted service to be integrated across multiple platforms and to be used by an entire group of individual clients.
And all this irrespective of whether they want the same or a different protocol.
Now if I were to point out some of WCF's heavy-weighting features in your decision-making process, “WCF or Web API”, they would have to be the following:
- it enables you to develop web services meant to support several transport protocols (TCP, HTTP, UDP, custom transports) and to “cope with” switching from one transport protocol to another
- any client least a bit familiar with XML syntax can use it (yet, it's not open source)
- it supports HTTP protocol only
- it supports developing web services complying with the WS-* standards (e.g. Reliable Messaging, Message Security, Transactions)
- it supports XML, JSON and ATOM data formats
- it enables you to build web services that support various encodings (Binary, Text, MTOM) of the same message type
- the WCF SOAP services can be described in WSDL, hence enabling automated tools to produce client proxies even for services with complex schemas
- it ships with the .NET framework
Security in WCF and WEB API: And the Winner Is...
In a "WCF or Web API" competition at the level of provided protection, it looks like WCF might be the “winner”.
I need to admit that both frameworks meet decent security standards.
Yet, WCF has the clear advantage of guaranteeing you an “enterprise-level” type of protection, including a security shield compliant with the WS-I guidelines.
And yet (for there is another “yet”): although Web API uses general web practices to enforce its layer of protection (tokens, basic authentication etc.), RESTful services are more adaptable than SOAP.
This comes in (more than) handy in scenarios of outside services authentication (Windows Live IDs, Facebook, Google, Twitter).
WCF or Web API: Which Use Case Matches Yours?
Now that I've walked you through the 2 rivaling frameworks' feature sets, let me present to you 4 specific use cases when you're better off with one or the other:
- use WCF if it's a web service “capable” to use fast transport channels (when available, of course, channels such as TCP, UDP, Named Pipes) that you need to build; a web service equipped to support HTTP whenever all the other transport channels aren't available
- use Web API if it's a web service that should be accessible to lots of clients and quick to be displayed on lots of different devices and browsers that you're building
- use WCF if it's a web service expected to support specific, particular scenarios (e.g. message queues, one way messaging...) that you need to develop
- use Web API if it's a resource-oriented (over HTTP and using its entire set of features) and not a service-oriented web service that you need to deliver
… simplify your selection method to 2 essential questions:
- Is it an intranet that you're building? Then choose WCF
- Is it an external web service that you're developing? Then go with Web API.
“Thorny” problem solved!