Choosing between SOAP and REST style web services for an architectural solution should depend on the consumers of the service in my opinion. To help me make the right decision I decided to draw up a comparison matrix below showing the pros and cons of each service style.
Having comprehensive toolkits make development easier.
|Toolkits are not required. However additional work is required to map URI paths the specific handlers.|
|Describing available Interface definitions.||Generally a WSDL is available to describe the available contracts and by using client tools proxies maybe easily generated||A document is normally manually written and is published as a web page. There is a machine readable version called WADL but is not widely used.|
|Message format||XML based format. Has SOAP and WS-* specific markup. This can make the payload quite large.||Can craft your own however common formats are XML or JASON. Does not require XML parsing.
Human readable results.
|Message Transport||Can use a number of transport protocols such as HTTP/S, TCP, SMTP, UDP, JMS etc||Normally HTTP/HTTPS. Other protocols are supported with extra development effort.|
|Message contracts||SOAP requires a formal contract to exist between the provider and consumer.
If rigid type checking is required then use SOAP.
Focus is on accessing named operations.
|Has a form of dynamic contract and relies on documentation. Focus is on accessing named resources.|
|Handling of complex domain objects||Complex domain models can be easily represented using soap.||Not so easy to handle complex models. Excellent choice if you only require CRUD operations over a RDBMS.|
|Transactional support||WS* protocol supports transactions which is geared towards SOAP.||Has no built in support. The HTTP protocol cannot provide two-phase commit across distributed transactional resources.
|Reliable messaging||Built into the WS-* protocol. Has built in successful/retry logic.||Clients need to deal with communication failures.|
|State management||Supports both contextual information and conversation state management.||The server cannot maintain any state. State management must be handled by the client|
|Caching||No supported||HTTP Get operations can be cached.|
|Message Encoding||Supports text and binary encoding||Limited to text only|
|Testing of services||Requires unit tests to be developed or 3 rd party test tools.||Can simply use a web browser and view the results.|
|Security||Supports enterprise security using the WS-Security protocol. Use SOAP if intermediary devices are not trusted.||Use SSL protocol for point-to-point.
Also can easily identify the intent of a request based on the HTTP verb.
|Maintainability||Easier to maintain due to tight data contracts and standards.||In the long-run can be much expensive to maintain due to lack of standards|
|Popularity||Mainly in enterprise applications that required WS-* features.||Used by most publically available web services.|
My conclusion is there is no right or wrong approach for building web services with either SOAP or REST, it depends on the requirements of the consumers.
I tend to lean towards REST for CRUD type web services that integrate with websites and SOAP for integration between critical enterprise systems that require the WS-* features such as transaction support and reliable communications.
I hope anyone reading this will find this blog helpful in making the correct architectural decision and please let me know I have left anything out.