REST Architecture + Leonard Richardson and Sam Ruby + Book + O'Reilly =
by M. David Peterson
REST Web Services
What we are doing
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.
Our project has technical aspects but it's mainly a job of evangelizing: spreading the good news. Currently the REST philosophy is typecast as sloppy or unserious. This despite the fact that:
Most of the web services the public actually uses are URI-based.
Most Ajax applications are nothing but browser clients for URI-based web services.
Most of the world's biggest web applications are technically indistinguishable from URI-based web services.
If REST doesn't work or doesn't "scale", then neither does the World Wide Web.
REST is typecast because its practices are folklore. It's got no canonical documentation beyond a doctoral thesis which, like most holy texts, says little about how to apply its teachings to everyday life. Its technologies are so old and heavily-used they seem undocumented and unsupported when their true power is revealed. It's like finding out you can pick a lock with a paperclip.
Because it occupies this odd middle ground--familiar yet suddenly cast in a new light--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.
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. We're doing programming to improve tool support and introduce new kinds of tools. We're doing marketing and memetic engineering to make REST a more fit competitor in the marketplace of ideas. Some may find our methods heretical; others may see no method at all. Personally, we see six: GET, HEAD, PUT, POST, DELETE, and sometimes OPTIONS.
From the same linked page,
If all goes well, REST Web Services will be published by O'Reilly in May 2007. We want this to be the definitive work on the real-world use of REST. If you're a REST fanatic, we need your input now: your best practices, rules of thumb, and folklore; your review of what we write. If you're just interested, we need your questions and concerns. Please send email to Leonard (email@example.com) to get in on this project.
Go! Now! Hurry!!!
Update: What are you waiting for? GO!!!!!
|We're getting a huge email response, and several people mentioned your site explicitly, so I think people are heeding your commands. :)|
|M. David Peterson
|I hope this book covers some best practices for designing REST applications using the ATOM API REST spec. I know that spec is still evolving, but I've found ATOM very useful and would buy the book in a minute if it helped me with my projects using this.|
|M. David Peterson