Restful versus SOAP–Is SOAP Obsolete?

REST is obviously taking over the world of web services. However, there are several vendors still pushing out SOAP compliant APIs and providing services that are SOAP based. The reason for this is many-fold.

Atomicity and Transactions

Only SOAP, through WS-AtomicTransaction provides complete ACID in the web service world.

Security

In addition to standard SSL  support, SOAP provides WS-SEcurity options. These can be thought of as message level security (encrypting parts of the soap message), as opposed to transport level security (which SSL provides).

One might ask, why do we need message level encryption when the entire transit is encrypted at the network level?  That’s just the point – SSL takes care of in-transit encryption – but the actual soap message is unencrypted. If, for instance, your web traffic is routed through a proxy server, the SOAP message is decrypted at the proxy – which means it passes into your network in plain text.

Advantages of REST

In a nutshell, simplicity is the biggest advantage of REST. REST doesn’t require a complex interface description language (SOAP requires WSDL). REST works with just XML or JSON (JavaScript Object Notation) and several other media types.

REST is also better performing (reads can be cached, for example) and scales easily. Amazon (and eBay) are primarily REST based.

Downsides of SOAP

Interoperability (aka Interop) has been a challenge with SOAP. Since SOAP is strongly typed, it expects servers (web servers) to understand what a client (browser or web client) means when it says  ‘I am passing an integer’ or ‘Here is an array’.  If you are trying to pass parameters from a .NET Client to an Apache SOAP service, you may encounter interop issues.  Whereas .NET SOAP (and WCF) supports multi-dimensional arrays as parameters, apache soap does not.  SOAP is very ‘breakable’ – changes in parameter types – even simple changes of the type that changes 16 bit int to a 32 bit int – can break all clients (consumers). Brittle is probably a better word to describe SOAP interoperability. Which is all the more ironic – since SOAP was designed to solve platform-to-platform interoperability issues. In all fairness, SOAP did a decent job for the most part – and worked fairly well – except when it didn’t. And the fixes usually were not life changing events – it was fairly easy to change from an ArrayList (in .NET) to an Array before passing it to a J2EE server.

Summary

For an enterprise grade SOA that requires both Transactionality (between successive message calls) and Security (message level security), SOAP is still more powerful  than REST. If these advanced security and transactionality features are ‘optional’, you may be better off with RESTFul services.