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.
Feature | SOAP | REST |
Development effort |
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. |
Client side development complexity | Toolkits are required to easily consume the service. | Can consumed by any client, even a web browser using Ajax and Javascript. |
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.
That is a really handy matrix, I will be sure to refer to it in the future. Thanks for the great post.