Courtesy of my employer, I am now a happy owner (well, I guess I am technically the possessor) of the excellent O'Reilly text
RESTful Web Services
. Upon reading the foreward, I knew this would be an excellent book:
A renaissance of HTTP appreciation is building and, under the banner of REST, shows a credible alternative to what the merchants of complexity are trying to ram down everyone's throats... [this book] shows you how to use those principles without the drama, the big words, and the miles of indirection that have scared a generation of web developers into thinking that web services are so hard that you have to rely on BigCo implementations to get anything done.
The book does an excellent job of clarifying a lot of the misunderstanding surrounding the concepts of REST and also does a great job of explaining proper web service development (with an emphasis on REST, of course). Although I am usually critical of most of what I read, I ate up nearly everything in this book. And, because the authors did such a good job explaining their stance on everything, I can still be pro-REST and understanding of RPC services (SOAP) at the same time. Yes, the book did reaffirm my belief that SOAP is bloated and unecessary for many applications. However, the authors could see beyond religious zealousness and admit that there are times when SOAP, or other complex message formats or web service styles are preferred. This was all in chapter 10, a chapter dedicated to comparing "resource-oriented architecture" (RESTful) to "Big Web services" (SOAP). Anyway, I could go on and on rambling about this book and my love for it, but why spoil it for you ;) Instead, I'll just post my big takeaways (many of these I already felt, it was just reassuring to see them in print).
- Use status codes appropriately
- Adhere to safety and idempotence definitions found in
Section 9.1 of RFC 2616
- SOAP over HTTP is a message transport mechanism inside of a message transport mechanism and is thus redundant
- Use URI's and query parameters appropriately
Although I felt I understood the concepts behind REST pretty well, this book explained a few things I didn't. It also armed me with the means to defend choices in web services design. Furthermore, now I have something more reputable than a blog that I can point a colleage towards. For long term value, the appendencies listing each HTTP status code, its importance, and when to use it is invaluable. I often see status codes used by their table of contents definition (406 Not Acceptable takes on new meaning when you actually read the proper usage in RFC 2616). If you would like a good education on web services and how to properly use HTTP, I highly recommend
RESTful Web Services. Enough of the book review... In somewhat related news, a 3rd party client at work recently rejected our initial specification for a proposed web services, stating that they preferred to use SOAP. Now, there is nothing wrong with that. I can understand why they want us to supply a WSDL so they can plug it into their favorite IDE and have it spit out an interface. Fine by me. Although I consider a SOAP interface to be inappropriate and overengineering the solution to the problem at hand, I gave in, knowing the customer couldn't be persuaded. At least it was a simple service, so I cranked out the WSDL and a working server (automatically generated from the WSDL, of course) in under an hour. Not too bad. Anyway, during further conversations with the client, we started talking about security for our B2B web services. Their first suggestion was to use WS-Security. My head almost exploded. I was expecting to hear the normal answer, which was to use transport level encryption (SSL). Not being fully up to date with the BigCo buzzword that is WS-*, and wanting to keep an open mind, I approached a few coworkers after the meeting and asked both the question, "what are the advantages of WS-Security over transport level encryption?" The first coworker laughed at me, gave me the I-know-you-are-a-better-engineering-than-to-be-asking-this-question look, and responded with something along the lines of "who the hell is wanting to use WS-Security?" The second colleage, whose job is more or less network security, gave a similar reaction. Anyway, both alerted me to the presentation,
Attacking XML Security, which was given at Black Hat this year. It does a great job of explaining why transport level security (SSL, firewalls, etc) is much preferred over message level (XML encryption, WS-*, etc). In a nutshell, SSL is simple, stable, and proven, whereas WS-* is complex, new(er), and not thorougly tested. In addition, WS-* gives attackers a larger attack surface, which includes XML parsers, protocol handlers, remote references, etc. Compare this to SSL, which has a single attack surface: the SSL implementation itself. Using the chain strength analogy, I would rather focus on one link (SSL) than many (with WS-*). Basically, "security's worst enemy is complexity." I guess we know what that makes WS-*.
