REST vs SOAP Web Service

There are some arguments regarding web service in my org recently. Shall we use REST or SOAP based web service? As a long time SOAP advocator, I am more favourite at SOAP web service because of its well-defined standards and well supported by all kind of tools. However, I cannot ignore the arguments from the opposite site. They have some good points also. For example, if the service consumer (SC) just need a simple product name from the service provider (SP) by passing a product code, and the developers of the two systems just sitting together. Why don't they yell to each other: "Hey, I put the product code in the HTTP request, and you give the product name in HTTP response", it's so simple! Why do they have to bother to write WSDL specification, and wrap a simple string into a bulky SOAP message, it wastes developing time and computing power also. That is a very solid point. So after doing some research, then laying on my bed and thinking about it for several days. The following are my finding and conclusion:



Pros of REST:

• Simple! Easy to develop, Easy to use. Less overhead to both SC and SP


• Not depending on other standards and specifications other than HTTP. It reduces the potential compatibility issues from both sides and also the problems in future upgrade


• Most developers feel more comfortable with the REST

Cons of REST

• Lack of definition language. The service specification is not machine readable, it relies on human interpretion which is error-prone. ( Someone may argue "we have WADL already", but does it defeat the advantages of REST? are you sure there will be only one version of WADL forever? and are you sure the deveopers will like WADL more than WSDL? so I will say the question is if we SHOULD use any definition language for REST, not if we have any)


• Limited to only one transportation mechanism :HTTP


• Does not support other QoS such as security


• Lack of toolkits (at least for now)


• May cause more problems in integration testing because of inter-person communication in designing phase.

Prons of SOAP/WSDL

• Well defined service definition language, and plenty of WS-* specs to support QoS


• Widely supported by most of COTS and open source vendors


• Many toolkits available to generate proxy/stub codes


• Guarantee working in integration test if everyone sticks to the same WSDL


• Not limited to HTTP, supports JMS and other mechanisms in sync and async mode.

Cons of SOAP/WSDL

• Too heavy and too complex, cause overhead on both sides


• WSDL is hard to write and not easy to read also, and the overwhelming WS-* standards are kind of scary


• Compatibility issues. The systems at SC and SP may use different version of standards and any one of them may upgrade to another version in the future. It requires carefull planning

Conclustion :

Whether use REST or SOAP based web service depends on the system context the service is used.

Use SOAP if you use contract-first approach. The following are some of the scenarios in which contract-first is a more approprite:

• The services is designed as part of enterprise SOA strategy;
• It is coase grained service;
• The SC or SP is unknown, the service is designed to be used(or provided) by any relevant party;
• The services are co-designed by SC and SP, and more than one SC is involved.

Use REST if you can use method first approach. The following are some of the scenarios in which method-first is more approprite:

• It is a fine grained service;
• The service can be decided by either SC or SP. One party can make the design decision;
• It is a simple service. The input and output are clear, no ambiguity;
• You just want to replace a proprietary remote invocation by web service;