REST Web Services and ROA
REST Web Services, a book in progress by Leonard Richardson and Sam Ruby piqued my interest yesterday. From the introduction:
"We want to restore the World Wide Web to its rightful place as a respected architecture for distributed programming. We want to shift the focus of "web service" programming from a method-based Service-Oriented Architecture that just happens to use HTTP as a transfer protocol, to a URI-based Resource-Oriented Architecture that uses the technologies of the web to their fullest."
"...a lot of people have gotten the impression that REST just means "whatever you want to do, so long as you don't use SOAP". That it's a sloppy no-methodology used to justify bad design, malformed XML, and, in particularly troublesome cases, Extreme Programming."
I've come across this perspective a few times and it is justifiable given some of the APIs I've seen described as RESTful. The intro goes on:
"To counter this, REST advocates have come up with a new term, "HTTP+POX", to describe URI-based web services that aren't RESTful. But that just brings back the arguments about what REST is and isn't. Is it like pornography, where you only know REST when you see it? Or is it like communism, where if a service fails it must not have really been REST? Can a service be somewhat RESTful, or is that like being somewhat pregnant? How many resources can dance on the head of a pin?
...We're writing a book to codify the folklore, define what's been left undefined, and try to move past the theological arguments."
My bet is that this project, the book and the concept of ROA as an effort to standardize aspects of RESTful architecture design is going to do very well, because I agree this is needed. Example provided:
- ""REST" is an abused term. Many alleged REST services (such as Flickr's, which says REST right on the website) are actually HTTP+POX: service-oriented APIs that happen to use nothing more the basic technologies of the web. Classifying services as resource-oriented or service-oriented makes it easy to see which ones are more and which less RESTful, without wasting time on minutiae."
In this post, Leonard further explains the idea behind the book:
"I got the idea for a REST book when I started seriously trying to figure out what was and wasn't REST. I noticed that though certain best practices showed up repeatedly in REST folklore, they never really progressed beyond that point. I decided to write a book that would set down the folklore and hopefully create some new canon, some common ground. I got Sam Ruby to agree to do the hard parts. And when I started work on the book I discovered a basic rule of thumb, a framing device that really focuses on what's important about REST, and makes it easy to tell what's RESTful and what's not.
We call this framing device the Resource-Oriented Architecture (we're not the first, but the other uses are compatible with ours), and I'm going to be writing about it a lot more in NYCB. It's too good to keep hidden in a book along with a bunch of implementation details."