Every so often, you come across a book that not only informs, but challenges your perceptions, leaving you seeing things in a way that you would not have before you started reading. I have a fair number of science fiction books that I’ve read over the years that left me in the major paradigm shift state after reading it (usually at about three in the morning), but its been rare in recent years that I’ve found a tech book that has done so. However, the book RESTful Web Services by Leonard Richardson and Sam Ruby (O’Reilly press, 2007) managed to do just that.
Pretty much since the inception of SOAP back in the late 1990s, I’ve felt that somewhere along the line something went horribly wrong in web programming … it lost the “web” part. The idea behind SOAP, of using a predefined envelope for sending messages, makes a certain sense, but it was about the time that WSDLs began to appear, with it’s ports and connections and services that the fundamentally simple paradigm of the web suddenly became this effort to try to turn web services into COM-like boxes, each of which had their own complex interface, and all of a sudden you couldn’t get Microsoft web services talking with their Java counterparts or integrating cleanly with PHP web services.
You can make the argument that the goal behind all of this was to make web programming so complex that it could only be handled by generators sitting in the background, generators that of course could only be tied into their respective proprietary platforms. Of course that’s so much silliness - no vendor would ever deliberately complexify the web just in order to lock in their customers, after all - so after a while I was beginning to think that after some twenty five years working with programming that maybe I was just a little too stupid to comprehend this new WS-* web … and so I went back to good old basic HTTP.
Curiously enough, though, somewhere along the line the AJAX movement came along, and Ruby, and Atom and XQuery services and the whole RESTful web sort of thing, and I began to realize that maybe, just maybe, the WS-* technology stack was so complicated because they just didn’t understand the way that the web really worked. And that was a rather disturbing thought.
You see, when the smoke finally clears at the end of the day, the web isn’t the big replacement to COM and CORBA and RMI and the whole alphabet of interchange formats. It’s simply a way to publish things. We PUT resources on the web, we GET resources from the web. Occasionally, we need to POST content, but the primary role of POSTing is not to provide an alternate way to pass larger blocks of content to the server … it is in fact just a way of appending content to a given location on the web. We need to DELETE objects occasionally, and we need to get enough information via HEAD to understand what a given service can do and OPTIONS to determine what that service can expose. The web interface is simple - you put things, get things, delete things. You don’t need a huge API that is exclusive to your server and that only works well with Microsoft clients to perform these basic things, and if you can subclass these operations you don’t necessarily even need them for more advanced ones.
This was the message of Richardson and Ruby. From the preface,
We wrote this book to tell you about an amazing new technology. It’s here, it’s hot, and it promises to radically change the way we wrte distributed systems. We’re talking about the World Wide Web.
Okay, it’s not a new technology. It’s not as hot as it used to be, and from a technical standpoint it’s not incredibly amazing. But everything else is true. In 10 years the Web has changed the way we live, but it’s got more change left to give. The Web is simple, ubiquitous, yet overlooked platform for distributed programming. The goal of this book is to pull out that change and send it off into the world.
It may seem strange to claim that the Web’s potential for distributed programming has been overlooked. After all, this book competes for shelf space with any number of other books about web services. The problem is, most of today’s “web services” have nothing to do with the Web. In opposition to the Web’s simplicity, they espouse a heavyweight architecture for distributed object access, similar to COM or CORBA. Today’s “web service” architectures reinvent or ignore every feature that makes the Web successful (italics mine).
Wow! If this isn’t a shot across the bow of the WS-* stack, I don’t know what would be. Richardson is well known in the Ruby community as one of the key RAILs evangelists, while Sam Ruby is an icon in the XML and web technologies spaces who has written extensively about REST and is, among many other things, one of the principal designers of the Atom news feed standard and the Atom Publishing Protocol (AtomPub). They are two of the most respected authorities in the field, and their mission here, quite simply, is to wake people up to the fact that the core web protocols, in place since the early 1990s, is still more than the match of any number of “proprietary frameworks” that purport to simplify web development and only serve to put an expensive, entrapping barrier between the simple web and the application developer.
If you are involved in web development in any capacity, get this book, commit it to memory, then read and reread it. Like many other books that are part instruction and part inspiration, you will find yourself dipping into this book at various points and extracting out gems and insights from every page, and in the end you’ll find that maybe, just maybe, the world really doesn’t need to be any more complex than it already is.
Kurt Cagle is an author, information architect and web consultant specializing in XML based technologies. He blogs regularly at MetaphoricalWeb.org and runs the XML News Network portal. He lives in Victoria, British Columbia, but is still rooting for the Mariners to get to the playoffs!
Where is the review of the book? I miss a little bit your opinion on the book. Or do you use the book to get the attention on REST?
I also like the RESTful style and also read the book.
My first reaction is that the book itself is a little bit chaotically. I was constantly asking myself, ok but what is REST now. But furthermore it is the first book about REST and i like and recommend it. We even are developing our web application the REST way!
Regards,
Roger van de Kimmenade
Inspiring Kurt, thanks !
I heard about REST via the Rails community and once I grasped it, would not consider developing web apps any other way (unless I had a real good reason).
Its good to know I am not alone in thinking that simplicity is they key to practicality.
Amen, Kurt! We've both said it before about 175 times (in the past 4 weeks alone ;-), but I think it's time we dust off the mic's and record another show in which undoubtedly we will both agree on this time around,
The importance of REST!
Wasn't one of the core design goals of SOAP to work over non-http transport? (I actually prefer the REST way of thinking, but thought it would be unfair to leave that out)
Also- isn't SOAP's main audience in java? I'm not terribly familiar with rpc in java, but it just seems like SOAP what java people look for first.
Roger,
I'd tend to agree w/ your assessment about the organization of the book, and a clear cut definition of REST could have helped early on, but I think that there were also a number of conceptual nuggets in the book that made it worthwhile. The challenge of any book of this sort is that REST isn't really a product, or even an architecture, but almost a philosophy, one embodied by HTTP and governed by simplicity. The example apps that they give made some sense if you program in Ruby, but overall I see this book as being as much a call for simplicity as it is a "programming" book.
Matthew,
SOAP started out as a messaging protocol, and there are non-HTTP instances of SOAP (such as SOAP over smtp:), but it's worth noting that the number of use cases where SOAP is being used outside the HTTP domain is vanishingly small. In principle, the proponents of SOAP tend to point to the efforts where its being used in messaging queues and the like as a messaging protocol, but again the evidence would tend to indicate that the majority of all SOAP usages involve an RPC invocation of an external class a la COM or CORBA, over HTTP.
In other words, there's something of the idea that "SOAP is a 'messaging' - wink, wink, nudge, nudge, you-know-what-I-mean - protocol", whereas in fact SOAP's primary purpose is and always has been to facilitate XML-RPCs.
SOAP was designed originally with an eye towards Microsoft COM services, though its application to similar tightly bound OOP-based systems like Java made a port to Java pretty much inevitable. I'm not necessarily saying that SOAP itself is bad - it has its place, certainly - but we've become so brainwashed into thinking that SOAP/WSDL RPCs are the sine qua non of programming and have lost site of the fact that they add a considerably layer of semantic complexity for frequently very little gain.
-- Kurt
NIST has just released its Guide to Secure Web Services which emphasizes SOAP and related "standards." I would be interested in how the Richardson/Ruby book addresses security concerns raised in this document.
One of the things that I picked up from Richardson/Ruby was that they readily recognized that there WAS a specific place for SOAP based services, though in general the assumption was that the primary issue wrt security on the REST side had to do with the transport security of HTTPS. This isn't necessarily an Achilles heel - HTTPS is comparatively quite secure, and more importantly recognizes that a packet of information is effectively only as secure as both its transport "pipe" and any encryption on the message itself. More to the point, unlike general HTTP, there is a tacit recognition that secure communications in general over HTTPS assume that both sender and recipient have already agreed upon a security protocol (either because the sender is also sending the client instance or because of an a priori arrangement).
SOAP by itself largely punts the security issue, which is one of the reasons why it became necessary both to built alternative WS-Authentication and WS-Security stacks into the ever-growing framework. One of the principle arguments of R & R is that every time you add to the complexity of the security stack, you also add to the possibility that such a system can be compromised, because that complexity in turn usually implies that at least part of this system requires unknown pre-generated code.
Overall, if asked whether SOAP based or REST based systems were more secure, I'd have to respond, based on R & R, that its a toss up. REST has fewer moving parts, and hence has less that can go wrong, but if you believe in the notion of security as building successive complex barricades between yourself and the rest of the world, its easy to see the appeal of WS-*.