WEB API VS WCF

Is ithis the end of WCF? The actual wrangle here is between SOAP and REST protocols. We've all certainly been hearing about how easy and simple it is to implement REST services especially using new frameworks such as the Web API. The fact of the matter is that sometimes keeping things simple is better than having a sophisticated solution. This is obviously not always the case and one has to assess all the advantages and disadvantages of simplicity over sophistication before desiging a new system. In this blog we'll discuss the flexibility of SOAP compared to the simplicity of REST. We're going to be using the WCF and Web API Microsoft frameworks to compare the differences and understand how each works. 

Big old WCF

 The WCF frameowrk works on several communication protocols apart from high application level HTTP. It was initialy designed to allow the integration of SOAP services over multiple transport levels such as TCP, UDP, HTTP, PCM and pipelines. The idea behind SOAP was to use an XML based protocol to define the message encapuslated in an envelope containg a header to transfer information over several protocols. Although SOAP is wide spread and supported on many other platforms, it was clear that it is not the only way to go when creating web services. There was also a need to support non-SOAP content within the message such as JSON, plain XML or any other content which might be consumed by the consumer of the service. There was the need to use the power of the HTTP protocol; the ability to activate a request by a 'GET' send plain XML in the body, respond in JSON and make better use of URIs. 

With WCF 3.5, the introduction of the WebHttpBinding was aimed at targeting these issues and allowing the WCF framework to support RESTful services. The WCF framework was built to allow several configurations of serving and consuming services and in order to support the new RESTful services there were quite a few configurations which had to be made first. There was an overuse of the CLR attributes to define the 4 main HTTP calls POST/PUT/GET/DELETE. The WCF team was trying to solve these problems by producing a WCF REST Webstarter kit which was never officially released by Microsoft. 

WCF Web APIs

Thats when Microsoft started working on the Web APIs which were known as the WCF Web APIs back then. The idea was to stop using the HTTP protocol as just a transport protocol to pass requests as it was used by the traditional WCF framework. They started looking at the HTTP protocol as a powerful, rich, interoperable, resource orineted protocol which could possibly provide a strong alternative to SOAP services when compatibility was appreciated more than speed and flexibility. The main purpose of the WCF Web API was to make more use of the URIs in order to target resources over HTTP and to use the header and body to define the type of operation and send/receive content. The advantage of SOAP services over HTTP services was that the knowledge and info are all combined into the message itself irrelevant of the transport ptotocol. However since HTTP is an application-level protocol, it is able to offer some other great features of its own including:

• Verbs support to define actions
• • GET - Query information
  • POST -  Place new information or update existing data
  • PUT - Same as POST but will create the resource if it does not exist
  • DELETE - Remove information
• Message Headers which are very descriptive including the content, type, cache information, how secure the content is etc
• Body can contain any type of content  whether its plain XML, JSON, binary files etc
• Utilizes URIs for identifying both information paths (resources) and actions 

So it is fair to say that HTTP is a lot more than just a transport protocol. It is an application-level protocol which is supported by the most populat platforms at the moment; web browsers. Web browsers do not natively support the SOAP protocol, it requires alot of XML parsing and DOM querying. Even though SOAP can be used to transfer messages across different platforms including lower-lever protocls such as TCP/UDP, there are more platforms which support HTTP and that makes it a very strong candidate when it comes to choosing your web service framework. 

Moving from WCF WebAPIs to ASP.NET WebAPIs

The problem with the WCF framework was that it involved a lot of configuration, even if you had to configure simple REST services because it was originally built to support more other types of services. Along the way, the ASP.NET Microsoft teams were working on a very elegant architecture, the ASP.Net MVC framework which makes it very easy to make HTTP requests/repsonses using the easy-to-create controllers. Consequently the WCF and ASP.NET teams joined forces and decided to use the MVC infrastructure to incorporate the WebAPI framework.  They focused on the world of REST/Hypermedia/HTTP services for the web works and thus came up with the ASP.NET Web APIs. The modern Web API framework allows developers to use the convention over configuration principle to easily implement REST services using controller-like methods representing the REST-supported calls.

Is WCF dead?

Back to the original question, "Is this the end of WCF?" The answer is "Probably Not". The reason being is that there are still scenarios where you are still more concerned about speed, configuration of your messages (message queues, duplex communication etc) rather than just simple REST web services. For this reason the WCF framework will still have its purpose. On the otherhand if you're focused on exposing services which will most probably be consumed by a browser platform, the WebAPI framework is probably the way to go. Its very easy to use (most of the configuartion is done for you by the ASP.NET MVC framework) and it is constantly being updated and supported by Microsoft. In future blogs I would like to present some example of how you can use the WebAPI framework to build REST services.

Thats all for today, to conclude this blog I want to add a table published on the MSDN website where it compares both services. Whenever you're in doubt of whether to use WebAPI or WCF for your web services, I would suggest that you take a look at this table and check which of the frameworks will best satisfy your needs. 

 Thank you for reading!

Shaun