RESTful Web Services: A Review

by Kurt Cagle

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.


2007-09-04 01:31:31
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!

Roger van de Kimmenade

2007-09-04 02:36:07
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.

M. David Peterson
2007-09-04 06:26:41
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!

Matthew Sporleder
2007-09-04 09:58:14
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.

Kurt Cagle
2007-09-04 10:05:57

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.

Kurt Cagle
2007-09-04 10:15:21

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

Mark Kelly
2007-09-06 09:03:07
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.
Kurt Cagle
2007-09-06 10:26:39
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-*.