RESTful SOAP

Last week there was a big debate going on between REST and SOAP camps in the office. Mails were flying both ways with the arguments. It was very interesting as both were right in their views. Here I would like to put forward my views on web service based on SOAP as well as REST.

REST is the acronym to the architectural style described as REpresentational State Transfer. In this philosophy, web services are viewed as resources that can be uniquely identified by their URL s. This is an extension to the current web architecture and this style merges with the underlying HTTP protocol. As a matter of style URLs need not be physical one and need not reveal the implementation technique used. One needs to be free to change the implementation without impacting clients or having misleading URLs. The protocol method itself is used to denote the operation. For example to retrieve a purchase order in which the order ID is ‘abcd’, make an HTTP request using a GET operation. In this case, the requested URL would be http://servicehost:8080/restfulwebservice-war/orderservice/abcd. Applications can consume RESTFul service either programmatically or through using the browser. It highly suitable an AJAX based application as the integration is implicit.

SOAP based services are popular and are more in numbers as the implementation is considered. They are more formal in nature with various standards and description mechanism. There is an evolving webservice stack based on SOAP standards grouped under WS-* standards. It includes standards for security, transaction, reliable messaging etc. Also SOAP based services are well defined using WSDL. SOAP is an application level protocol and it is transport independent. So here the underlying transport layer is abstracted.

So which is good SOAP or REST? As both camps are backing their style with valid points, it is confusing for a practitioner to choose. In REST the service leverages the HTTP transport for accomplishing the tasks. But it is useful for developing services over HTTP only. Even though most of the current services are HTTP based, there are large amount of candidate services, especially for asynchronous web services, that works better with other transports like JMS and SMTP. More than that basic architecture philosophy is to “abstract where ever possible”. SOAP based services are very much obeying this rule.

Another principle is to program against a well defined contract. In case of SOAP based service WSDL gives a proper definition of the service and the consumers required to get this alone to invoke a service. I am not denying the existence of WADL but it is not matured enough to compare with WSDL.

In case of webservice security REST camp argues that they use the existing server and network infrastructure to implement security and there is no message level security is required for it. This is true when there is only provider and the consumer is required. But in a case where there are more services involved in a business operation and the message contain various parts and each are intended only to the respective service, the scenario is different. Here message level encryption is the only way. In most of the enterprises this is the case as point to point integration is fading out.

Another advantage REST camp mentioning is the performance and the size of data transfer. In SOAP the overhead of the protocol is there and hence the data size is much more than that of a REST counter part.


After hearing all these I could draw an analogy between a formal programming language like java and a scripting language like PERL. Both has its own merits and demerits.
In an enterprise integration of various applications are unavoidable. In such conditions adhering to the standards are most important because modification of the individual applications should not get affected by the implementation of other applications in the field. Here the vote goes to a more standard based SOAP service. A large software application can be designed as a collection of loosely coupled modules and the interaction between the modules can be made as service invocation. Here performance and ease of development are vital and it is worth to give a shot to RESTful services.

Both are not competing technologies but complement each other. Both have their on space in the technology landscape and selection of any of these styles should depend on the scenario.

Be Pessimistic!

Pessimism is not considered as a frill to human nature. People often are being criticized for their skepticism. Is it all that bad? If we take it as being extra cautious or being alert may elevate status of this nature. But what is the relationship between pessimism and software architecture? Let me try to unwind this thread. A software architect, especially enterprise architect, is the one who takes the technology affecting decisions in an enterprise. His decisions can make or break the IT projects and even affect the business. He takes the final call on the technology, software are infrastructure in an enterprise. Current technology landscape is poised with so many products and technologies decorated with nice buzz words. There could be fakes also and it is very easy to be deceived by these traps. So a good architect should be vigilant and should not accept by their face value. He should really have a taste of it before serving it to the rest. But it may not be possible in all the cases. However some of the enterprise wide product evaluation should undergo through inspection of all the alternative options against the cost Vs. benefit. This need not be mere monitory details but in all the possible aspects.

The term SOA is a popular mantra for last few years and some of the IT managers and architects tried to make their project as SOA based. Service oriented Architecture (SOA) is a very good architecture style to make the IT assets reusable and loosely coupled. But there were quite few projects adopt this style by making webservices for everything just for the sake of being the first runner. Some of these projects failed due to poor performance and evolving standards which made them obsolete. The same was the fate of most of the J2EE projects in late nineties, where EJB was a craze. An architect, who aspire success, should approach the technology evolution with a critic's nose.

I know one of my fried who used to Google anything with a suffix ‘S..K’. Every coin has two sides!

Why do we need comments?

Yesterday I was reviewing some java code and it was more or less similar to the one given below.



//Assign i with the value 0

i=0;

//increments the variable i

i++;



Here each and every line is accompanied by some sort of comments. Some programmers believe that good programming practice is to write as much as comments you can. In the case of programming in machine language and or assembly language this is required and will be helpful to understand the program. But will it make any sense in the case of contemporary high level languages?

I certainly believe no. All the modern programming languages are English like and human readable. So if the code itself is meaningful, what is the need of repeating it again? I believe that the code itself is the best document for it. The benefits of practicing this is multi fold. Apart from saving a lots of human effort, the code looks clean and compact. This gives a macro picture of the logic at a glance.

So does it mean commenting a program is that bad? Not at all.
Comments are good aid for the reader if it is given to a set of cohesive statements. This also helps to visually separate such blocks like a paragraph in an essay. Languages like java and c# allows document style comments and this will be highly helpfull to generate the API document. It is good practice to document all the classes and methods with API document style comments.

A well written code is like a poem where it can be appreciated even over the phone. So you can do a simple telephone test to find out the readability of your code. If the listener is able to understand the logic then obviously you have passed the test!