SOAP or REST WebServices
When we start designing the Architecture of any Web Application, architects generally think what to choose? REST or SOAP
In this blog I am going to describe few design principles based upon which you can choose either SOAP or REST
History of WebServices
Webservices were built in the last 10-15 years in layers, where each layer resolves some of the technical issues faced by architects. It started when people think that we can use internet to transfer the data internally or globally. The process started with the use of HTTP protocol. However this protocol is restricted in some ways and thus big software companies spending their time in building a new protocol SOAP (Simple Object Access Protocol) which extends the HTTP capabilities to allow objects to be called remotely over HTTP. This protocol was a big success and lot of internet applications started using this. However as applications required more and more capabilities from the protocol one more layer was added in 2005 WS*. As the research in this subject goes on, we might see few more layers on this in coming years. If, SOAP webservices are built from the last so many years and have lot of capabilities then why some of the architects not prefer these? The answer is: to create a simple SOAP webservice we need to understand various protocols and architecture styles and this caused some of the developers to ignore the new technology/ standards and continue to use what they know.
The other issue is the wrong usage of Http verb in SOAP. The webservice Soap requests use the HTTP POST verb to transport request to the end points for the operations. Now if the method is just retrieving the records, then this should be GET. SOAP resolves this issue by having the standards naming conventions for the retrieval method by naming them as GetCustomers (prefeixing the methods with Get) but this is in the hands of developers.
Now REST (Representational State Transfer) Services: some researchers tell that REST should be the only design applied to the HTTP based services.
The greatest asset of REST based service is its pure elegance and its simplicity. REST is based upon the Resource Oriented Architecture. REST services do not require you to design your own service contracts, because you can rely on HTTP verbs to describe intent. This radically simplifies your service’s design. HTTP defines the verbs GET, PUT, POST, and DELETE. By using these built- in verbs, REST services provide access to resources via a Uniform Resource Indicator (URI) and an HTTP verb.
Now the question is which technology to choose. Well both has some advantages and some disadvantages. In most of the cases I would prefer REST because these are simple and what I believe is that “Simplicity is the key to success for big applications”. Does that mean it is end for SOAP, Not really. There are some cases where you might need to use SOAP because REST is somewhat limited, like you don’t have duplex message exchange pattern in REST.
Here are few of the things not supported by REST but available in SOAP.
REST only supports text based encoding whereas SOAP supports other encodings binary
REST doesnot support duplex message exchange pattern which is available in WS*
Only transport security is available in REST whereas WS* supports additional like WS-Security, WS-SecureConversation etc.
I am concluding on the blog by saying: This is very important for architects to choose the right approach for building services but always focus to keep things simple but secure so that community can consume your services easily. In my coming blogs I will focus on Ado.Net Data Services (Astoria), one of the very good project by Microsoft which allow us to create REST services. (generally we found Microsoft introducing complexity with every new release but this time things are changed and Microsoft is looking for simplicity and understanding the needs of the industry well.)
