Today I wanted to open a conversation comparing two different dot net implementations of web services. Windows Communication Foundation (WCF) has been with available for many years, and is quite powerful. A later technology started as a RESTful api, hosted originally in WCF, but was later released as Web API. Both implementations have grown to be mature products.
WCF was a simplified way of developing SOAP based web services. The SOAP specification made it possible to share objects and methods with dissimilar systems and languages, without knowing the internal implementations of the service. You simply retrieved a definition of the service in an XML form, and were able to consume the objects and methods by following they contracts specified in the service. WCF made it possible to write SOAP enabled libraries in Dot Net, without having to learn all the complicated XML specifications of SOAP. You simply implemented certain framework requirements, and the framework wrote all the SOAP specifications for you, and could even implement the SOAP wrappers in IIS without you knowing how it worked.
Web API does not use SOAP as a communication technique. It provides a RESTful web service. RESTful web services utilize verbs that already exist in the HTML specification for Get, Put, Post and Delete. These verbs may be used as wrappers to enable methods required by your application. REST does not have data contracts, like SOAP.
Data is simply passed and retrieved in the form of JSON serialized objects. So, while you may use objects as a client or a server, passing data between each is handled through JSON objects. This differs from WCF. In SOAP, the service defines all data, and provides the data specification through SOAP specifications. In RESTful services, the data specification of both the Client and the Server must be the same in order to work, but they are defined individually, without communication of the data definition between the Client and the Server.
Personally, I have been using Web Api for the majority of my Web Services. Recently I had need to extend some WCF web services, and was reminded of the difference. Because I hadn’t worked in WCF for some time, it took me a little bit to be re-acquainted with the data contracts, and their implementation to get things working. I was also reminded that the configuration between the client and the server must be synchronized for operating parameters and even security. I think if I had been more proficient with WCF I could have completed the work in probably 10% more time than it takes to do a Web Api implementation.
So, I’m asking myself, “why do I use one over the other?” Is it simply personal proficiency? Am I simply trying to get stuff done quickly using a technique I know well? Or, am I avoiding the extra work that comes with coding WCF, and managing all the deployment configuration issues that have to be just right? Am I willing to give up the strongly typed contract between Client and Server for the ease of implementation resulting from code by contract? So far I don’t have a compelling answer. If I did, I would have replaced one implementation with the other. For now, I do both. I will say I lean toward Web API for now code simply because I can get things done faster. So far I haven’t missed the strongly typed data contracts, and the RESTful verbs and syntax are adequate for implementing methods I might need.
Do you have any perspective on this question? I think it is hard to evaluate if one is better than the other except through some sort of performance test. Other than that, it seems more of a syntax preference than anything. Why not get into the conversation by leaving your comment below.
Cheers,
Ben