REST-lers++, SOAP-ists--

The SOAP versus REST debate reminds me of the EJB versus POJO arguments years ago. When EJBs first appeared on the scene, the Java developer community embraced it with full vigor only to realize later that it was not the wisest thing to do. EJBs were over-complicated with convoluted, inter-twined component, security, configuration, transaction and application models. They were designed with very specialized, complex, enterprise-scale scenarios in mind - scenarios irrelevant to most applications. Frameworks such as Hibernate, Spring and JDO, and simpler design patters with POJOs showed the way towards a more elegant approach. As a result, the developer community today is far better off.

SOAP has the same pedigree as EJB. SOAP originated primarily to serve the need of .NET-to-Java integration within the enterprise firewall. The myriad of WS-* specs were geared towards complex security, reliability and transactions involved in inter-system communication within large enterprises. Like EJBs, SOAP was embraced quickly by the developer community since it represented the first real standard for interoperability since the failed promises of CORBA. With HTTP transport and XML-based payloads in typical implementations, SOAP seemed like the perfect solution for all inter-system communication. However, like with EJBs, the developer community has come to realize that perhaps we have been on the wrong track by adopting SOAP for everything. REST-full patterns have emerged that seem more appropriate for a vast majority of applications and are becoming more and more popular. The abuse of SOAP-based Web Services will hopefully continue to diminish. REST has done to SOAP what POJO frameworks did to EJBs.

One of the issues with REST is the lack of a formal standard. REST is simply an architectural pattern rather than a standard like SOAP. If you wanted to publish to the world a formal API to access your system, SOAP offers a well-understood, tooling-friendly WSDL format. REST has no such standard - until now. JSR 311 JAX-RS spec represents a first step in more formalized standards for REST which will go a long way towards its wider adoption.

Talking of standards, it was interesting to see an entire keynote from Microsoft at JavaOne 2009 (yes, the evil empire at JavaOne) addressing SOAP interoperability. After all these years of SOAP standards, we are still figuring out interoperability between .NET- and Java-based SOAP implementations! To me that says a lot about the complexity of the SOAP standards.

To be clear, SOAP does have its place. SOAP is useful in complex enterprise scenarios involving things such as:
- end-to-end rather than point-to-point security
- non-HTTP transports
- 2-phase commits across heterogeneous systems
- guaranteed reliability and SLAs in messaging
A good articulation of this is by David Chappell here.

It was heartening to see a great deal of interest in REST at JavaOne this year. Clearly the "REST-lers" have scored a point over the "SOAP-ists". This trend is likely to continue, and like at the end of the EJB saga, we developers will be far better off as a result.