A lot of people often ask me if I feel that SOAP is dead and is ReSTFul web services the wave of the future. I read a lot out there that people like most other things go to one extreme or the other. There are some out there that give reasons for each, but few out there give real world examples where one applies over the other. I will attempt to do that here.
Why Web Services?
Using WCF or ReSTFul web services make a good first step effort for separation of concerns from you Data Access Layer and you User Interface. There are countless reasons this is a good idea, but I will leave that type of talk for a Design Pattern blog. Web services also provide a tool to many vendors and software companies a way to allow mass consumption to their customers. Also, if done correctly, consumed from any device regardless of the operating systems.
WCF and SOAP
So if ReSTFul is so full of awesomeness, why not just throw WCF away and say screw it. Here’s the thing, SOAP provides something very powerful called a contract. A contract allows one to provide a client (web or otherwise) the ability to know with confidence what is going to be returned to it, in what order, and of what type. The other wonderful thing this contract idea provides is the ability for strongly typed data between your web service and any .NET applications which consumes them. With that said, there are good reasons for ReSTFul services as well, especially when venturing into the world of the Internet.
WCF has also been around for many years and has been used in countless applications. If you are purely a .NET shop and most of what you will be doing will not be interfacing with other companies, then WCF is still in my eyes, the best solution. It not only continues to use the same .NET framework your developers are familiar with, but also provides RAD systems that you can add to and develop over time with little consumption headaches throughout your .NET applications (software, web or otherwise).
Although the WCF Team has tried hard to successfully turn WCF into a ReSTFul service, they were not very successful ( WCF WebHTTP, WCF REST Starter kit etc.)
ReSTFul services are best described as services that respond to HTTP verbs as from various clients. Because this is a standard in the HTTP protocol that all browsers and applications with HTTP support must abide by as well as their accompanying frameworks, any application (.NET, Java, Python, Objective-C etc.…) or browser( IE, Safari, Mozilla, Opera etc.) will have the ability to request data from this web service and receive data that it can then deserialize into whatever object it might be.
Sounds like a no brainer right? Well here’s the problem, while this is great, an issue that has continually been an issue with these services is API documentation. Without documentation, the customer or consumer of the web service must guess what the object coming back actually is and in what format (JSON, Text, XML etc.). This means the consumer of the service must either contact the creator of the service or use a tool like Fiddler to inspect the returned headers. So although a great idea in theory, relying on documentation ( accurate documentation) can be a bad thing to be relying on for your newest project to succeed.
Many will say “ Well those services or companies won’t succeed). This is quite the contrary. You wouldn’t believe the amount of times I have experienced myself or read others whom experienced the horrors of poor or outdated documentation on a ReSTFul service that the development team of that service just assumes you’ll “figure it out”. Now, if you have a SOAP service that is consumable, there are certain things that the .NET framework ALWAYS does which gives you insight into poorly documented web services and what to do to deduce what the developer was doing quickly.
Lets get married
So, these both sound like awesomesauce solutions… Has anyone come up with ways to use both technologies?? Well, I’m glad you asked that question because the answer is YES. Although it has just been released by Microsoft out of beta, it has been on CR for a while now and most of the bugs have been worked out. It has been called WebAPI. This web service application allows you to have several things:
- You can choose to attach it to the same project as your web application
- You can use it to provide ReSTFul consumption with other types such as JSON and XML all in one fail swoop.
- It provides a familiar framework to the ever growing popular ASP.NET MVC framework.
- It ships with excellent support for HTTP error handling
The list continues to grow as I learn more, but it is a very promising solution to peoples indecisiveness on which solution type to use. As I hear more, I will create new posts on what WebAPI is and how it works, but for now, that is all…