Simplicity is a virtue. And in software development, it's an essential virtue. The venerable
Jargon File has long had a particularly good adjective for systems that aren't simple: They are
baroque.
What I'm talking about specifically are today's web service protocols. And in particular the two sides of that coin: REST and SOAP. If you scroll down to the January 26th entry, you'll see a diagram of the current view of the standards-obsessed web services stack. It's packed with WS-* protocols and standards of every description. I can even use Google image search to turn up a dozen varieties of this diagram with little effort.
But I can barely find one diagram depicting REST (actually a feature, it doesn't necessarily need one). The one I do find, using the keywords "REST web service", is actually Roy Fielding's diagram, direct from his Phd dissertation which originally described the REST approach.
Almost everyone has at least heard of SOAP. Few people have heard of REST. But both are jockeying for the mindshare of developers trying solve problems building applications on the web. REST by virtue of existing, and SOAP largely by virtue of backing by software vendors and standards bodies.
SOAP also happens to form the underpinning of a veritable constellation of interlocking protocols. These protocols conveniently provide every conceivable capability from security and orchestration to transactions and management. On the other side, REST is a simple, easy-to-use convention that allows XML state to be exchanged via a basic HTTP service.
So SOAP has mindshare, marketshare, tool support, and a certain 'coolness'. And few have heard of REST (yet). But in a very unassuming fashion, while SOAP users struggle, REST has been helping folks get their Internet applications built, including big names like Amazon, whose now famous claim that 80-85% of all their web services clients use REST has even been trumpeted by the likes of Tim O'Reilly. My proposition is, if most of Amazon's customers prefer REST to interact with, then it's important to understand, as architects, why.
There is a growing perception (see James Governer's recent MonkChips entry) that REST is practical, simple, fast, and scalable, and SOAP is byzantine, damn hard to use unless you're in someone's officially supported environment, and slow. Let's take a closer look:
REST itself is just a convention and requires no toolkit or SDK. This is a large part of its power: You have everything you need if you have an HTTP server and an XML parser:
REST Web Service Conventions:
- Plain XML is the data representation format.
- HTTP is the transfer protocol.
- HTTP's GET, POST, PUT, and DELETE are the access/manipulation verbs.
- URIs point to individual data records (such as catalog items or customer info).
- HTTP authentication and SSL provide security.
REST Web Service Structure
But why should those considering SOAP think about REST? SOAP has all this and has the backing of IBM, Microsoft, and their tool support as well. Furthermore, there are all those other cool WS-* protocols in the web service stack that sit on top of SOAP that I can get access to. The reality is that few of these protocols are available today. Many are still in various stages of ratification, and won't be ready for prime time any time soon.
Here's what REST can do for you now. And you can get these benefits without buying or learning one new product, protocol, or SDK:
- Performance: REST is faster than SOAP, Amazon says up to six times faster.
- REST requires no additional standards and is based on well-known existing standards
- Learning curve is almost non-existent
- Is based on simple interactions with four HTTP verbs
- Stateless and can handle arbitrarily complex interactions
There is a saying in the agile methodology arena about forecasting features ahead of time. It's summarized as YAGNI, as in you aren't gonna need it. In general, most software, especially business applications don't need and can't leverage excessively transparent, and therefore complex, technology umbrellas. The learning curve, the maintenance, and the omnipresent bugs, often end up killing the productivity required to extract the value out of commitment to sophisticated frameworks. Especially when sophistication typically means a bewildering array of knobs and dials. COM never happened until Microsoft made COM libraries easy to implement in Visual Basic. CORBA never really happened at all. WS-* services are more likely to happen but less likely to work well between multiple vendors, especially as they keep changing.
In fact, I'm willing to bet that until WS-* technologies are fundamentally built into a platform, and perhaps into the next generation of web application languages, thereby making them invisible, that REST-style web service communication will be the de facto mechanism for the rest of the decade.
SOAP isn't a 'washout' as some are beginning to consider, but REST is likely going to be the mechanism that developers use to solve their problems until SOAP, and it's sister technologies, are embedded deeply and invisibly into the foundations of the tools and languages we use.
Technorati: Enterprise Architecture, Computers and Internet, Programming