My
article comparing REST vs. SOAP happened to make the
cover of this month's issue of the
Web Services Journal. I'm pretty excited of course, though the topic is already subject to overexposure in the blog community. But it is still poorly understood in the wider IT community and I hope it will let the hot air out of the arguments and let us get on to more important topics.
While comparing the two approaches directly these days is often considered to be comparing apples to oranges, I do believe it's a valid and more importantly, a necessary comparison. Projects around the world are striving to build real service-oriented architectures and applications that are easily interoperable across the Internet. Deciding the right way to do this is of critical importance to these efforts and their ultimate success. And when properly applied, for the right reasons, REST and/or SOAP will let them achieve true service-orientation.
Figure 1: April 2005 Web Services Journal covering REST vs. SOAP
For me, it boils down to this: There's no question that SOAP and REST are the two preeminent web services models today, the former a recognized standard, and the latter a compelling architectural style. Both are excellent methods for building interoperable services over a network or on the Internet. So, given this, clearly understanding the pros and cons between the two in various situations is something I find that people in our industry really want to understand.
As I say in the article, REST and SOAP are good for primarily different reasons, and hence different situations. That's not to say there aren't lots of projects for which both would be a good fit, and that's where the hard part is, making a decision. This kind of decision is a classic one for software architects: to make the best call on long term, pivotal design issues. I hope that this article helps clarify the topic.
Figure 2: Comparison of REST vs. SOAP
I do expect I will provoke some consternation in the camps of those who believe WS-I Basic Profile, and the SOAP, WSDL, UDDI hegemony, are the only valid way web services can be built. They do believe this out of good convictions though, specifically that without a fundamental web services standard, true interoperability amongst web services will not be possible. To them, I would say that they partially miss the point. REST is a brilliant, and the best, solution to building low-barrier-to-entry web services when your clients are highly diverse, heterogeneous, and the services are straighforward. The widest possible interoperability is achieved by using the standards everyone already supports today; this is the secret of REST's appeal.
On the other side, SOAP is a terrific solution in more homogenous environments with well-known client bases that want to consume sophisticated services, but it leaves those out that don't have tools that support SOAP and its WS-* extensions. As an example of the problem, see here for an interesting post from Simon Fell on his early experiences with interoperability using Indigo, Microsoft's huge, new SOAP/WS-* platform.
What constitutes sophisticated and homogenous is in the eye of the beholder of course. This doesn't change the fact that both web services models are terrific and proven approaches for delivering, as Aaron Skonnard says, both collaboration and interoperability with open-standards across the Internet.
For more on this topic, see my recent postings on REST and SOAP here:
- Can REST be considered a web service?
- Repeat after me: Be the contract, be the contract
- The hidden battle between web services: REST versus SOAP
- Who gets the credit for Web Services? Does it Matter?
Technorati: Enterprise Architecture, Computers and Internet, Programming