As the general concepts and communal understanding of web services continues to mature, certain folks lately have been asking some interesting questions about REST. A fast growing and popular workhorse web services style, applied in numerous forms by everyone from eBay to Amazon, REST continues to be used, misused, praised, and maligned across the web service community. But surprisingly enough, at the core of question for some, is if REST is even considered to be a web service approach at all.
In this vein, I've been thinking a lot lately about REST and reading the increasingly rancorous postings about REST vs. SOAP, REST vs. RPC, and even REST vs. web services. It's this latter question that took me a little by surprise lately when I saw Dave Orchard's recent post (slightly hyperventilating) about REST versus web services. I was taken aback mostly because it should be pretty self-evident that REST represents a real web service approach, and a pretty important one at that. Web services DO NOT have to be about RPC, and in fact, RPC is only one way of exchanging XML over HTTP. XML can be exchanged using an infinite variety of conventions inside HTTP packets. And the fact that REST uses HTTP verbs doesn't make it unfit for RPC, it just means that the convention for it would have to be defined by the REST web service itself, part of its charm really.
So it's interesting to me that often even very smart folks don't fully appreciate the distinction. SOAP is a fine method for exchanging XML messages, especially between like systems that have the same concept of SOAP and WS-* standards, but even SOAP considers RPC to be only a subset of what it can do; namely the standardized exchange of pure XML messages.
Now, before you get started, I know what you're going to say. A quick check with WS-I, the sometimes painfully earnest web services interoperability standards body, says that web services have to be built with SOAP. Or so says their most rudimentary interoperability standard, the WS-I Basic Profile. Unfortunately, while WS-I has a noble goal, and despite the fact that web services work only because easily consumed standards are used, I would emphasize that SOAP cannot be considered the lowest common denominator for web services.
Figure 1: Comparison of the growing list of WS-* standards with the simplicity of the REST standards
As some organizations try to build sytems upon dizzyingly complicated web services stacks, we tend to forget that web services are at their root only about exchanging information via simple but standardized web protocols over a network. The information carried by any real web service is information described in plain old XML and carried by a network protocol that should be old reliable HTTP. And I'm afraid that's about it. Anything else can only be considered gravy and not a minimum requirement. And yes, this means I'm saying the holy trinity of SOAP, WSDL, and UDDI are only a nice flavor on top of the real deal.
This doesn't mean you can't throw every WS-* protocol in the book into your web service and still call it a web service. Quite the contrary, SOAP provides powerful and compelling extension points that facilitate a very sophisticated and attractive method for layering and composability that would be pretty exciting to organizations that, say..... loved and were heavily invested in CORBA only five short years ago.
The reality is that real interoperability between hetereogenous systems is about simple, basic truths that can be easily and quickly agreed upon and met. Piles of standards stacked until they reach the sky make for fascinating problems in design and debugging that can only today work between highly homogenous (i.e. the same) development tools. But such monstrosities, err, implementations aren't useful to most folks who need real, easy, widespread interoperability.
This means that if I wanted to build web services that could be used far and wide regardless of platform, development tools, language, or development ability, I would choose REST plain and simple. And I would choose SOAP second. That's not to say I wouldn't use various pieces of WS-*, but only for the right reason, at the right time. So please, when you list the real approaches that allow web services to work in the most open and inclusive way, please, please put REST at the top of the list.
Technorati: Enterprise Architecture, Computers and Internet, Programming