RESTFul versus SOAP - the debate continues
REST is obviously taking over the world of web services and APIs.REST doesn't require a complex interface description language (like SOAP requires WSDL) or a proxy through which the consumer needs to access the service. REST also works just as easily with XML (what used to be SOAP's forte) or with JSON (JavaScript Object Notation) which is about as lightweight as data transfer can be. In addition, REST supports several other media types.So, it is no wonder that REST is taking over the SOA world. However, there are several vendors still pushing out SOAP compliant APIs and providing services that are SOAP based. Why, you might ask? There is a good reason (actually, 2 good reasons) for this.
State, Atomicity and Transactions
HTTP is stateless - which means that any state 'memory' has to be imposed on top of HTTP. Typically, this is done via the Session object stored in server memory (although it can as easily reside in a database or on a REDIS instance). When you start exceeding the few thousand - and getting into a million plus users, the in-memory Session storage can bring a server to it's knees.Along comes RESTFul to save the world from Sessions. It essentially passes all the information that would normally be stored in a session, in every RESTFul call that it makes. That's what the ST in REST stands for - State Transfer. Essentially, State STORAGE has been replaced by State TRANSFER. This has obvious advantages, server performance being one of the primary ones. However, this has an inherent disadvantage - no longer is each call part of any transaction - even an 'imposed' transaction as with a Session construct. No transactionality - also means, no rollbacks!SOAP, on the other hand, has a whole plethora of 'extensions' (WS-* Extensions) including one that provides transactionality. Through the WS-AtomicTransaction, one can have a complete ACID transaction in the web service world, something that REST cannot even begin to encompass.
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 intercepted by a proxy server (see my Cyber Security Team Training to understand how SSLs and PGP can be easily compromised), 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 (like SOAP requires WSDL) or a proxy through which the consumer needs to access the service. REST also works just as easily with XML (what used to be SOAP's forte) or JSON (JavaScript Object Notation) and several other media types.REST is also better performing (reads can be cached, for example) and scales much more easily than SOAP.
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 interoperability 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 for the occasional interop issue. 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
I promised you TWO good reasons in favor of SOAP APIs. And those reasons are TRANSACTIONALITY (ACID transactions) and ENHANCED SECURITY (message level).For an enterprise grade SOA that requires both Transactionality (between successive message calls) and Security (message level security, not just transport level security), SOAP is still more powerful than REST. It's no surprise that vendors are still publishing SOAP compliant APIs, even after the near complete dominance of RESTFul APIs.
Where Can I learn More?
Anuj Varma offers a crash course in Cyber Security, targeting all levels of attendees. He also offers a popular 1-1 customized, tech seminar targeting tech executives and containing real-world, success strategies.To learn about which technologies are hot and which are mainly hype, sign up for next month's Ultimate Technology Seminar.
- Data - Why NoSQL is both, disruptive, and yet complimentary to SQL (SQL is not going anywhere)? Why MapReduce is disruptive, but BigData may not itself be?
- Cyber Security - How can hackers break into your encrypted channels - including SSL and PGP? How do hackers gain root access to locked down systems?
- Cloud Services - Is your data truly safer in the cloud than it is on-premises? If Disaster Recovery and Failover are key selling points for cloud infrastructure, why is it that more and more companies are buying cloud 'insurance' (insurance against cloud services going down)?
Filled with real-world success stories, this is the one seminar that can save you millions of dollars, by simply adopting (or rejecting) the right technology offerings.