RESTful Web Services

What a waste of time. The entire book reads like a frustrated high school debater saying, "You're right, but I still think it would be better if I was right instead."

Richardson & Ruby "coin" the term Resource Oriented Architectures, by pointing out that it is actually a term previous used by a 2004 paper from James Snell, but they don't like the way he defined it so they are going to abscond with it and rework it.

They give very little insight into the possible benefits of their style of RESTful services, instead they spend a lot of time deriding "Big Style" web services, RESTful-RPC hybids, and other non-pure systems.

What I found really enlightening is how much the authors struggled to find successful RESTful examples. Everything from flickr, to Google, to del.icio.us, to Amazon have been doing it wrong and at best, the authors explain, are only half-assing it with RESTful-RPC.

All that tells me is that either the authors are the smartest guys in the world and can see what some of the web's best engineers cannot; or, REST simply isn't that compelling.

The book also simply is a failure at explaining what REST is and isn't. They make confusing and arbitrary delineations between one design decisions being RESTful and another not.

For example:
http://www.somesite.com/rest-service?method=search&q=penguins
and
http://www.somesite.com/rest-services/search?q=penguins

The first one, not RESTful, second one yes. The authors explain that the method should be the HTTP method: GET, PUT, POST, DELETE, etc.

The second URI invokes GET on the resource /search and passes some "scoping" information as "q=penguins." So for the search we can a scope of penguins.

I say that the first is the same. You invoke GET on /rest-service and pass a scope of ?method=search&q=penguins. At some point you are just going to get into semantics, especially once you get past trivial search examples.

They do similar fudging with RESTful services need to be stateless., but they use examples that must have some idea of who is doing them. If you pass the sessionID as a URI param, ok, as a cookie, you are not RESTful. Which makes sense in terms of caching servers, but on write operations, why do you want to cache?

The whole book is about proselytizing REST, usually by denouncing the false religions. It does not offer the reader a new set of skills and an honest discussion of what REST is good for and when should look elsewhere. There is not good discussion of the limitations of REST.

What do I do when the data I need to pass in exceeds the 1024 limit of a URL? What if I would want to create a set of simple atomic methods, but I have clients that would like to make coarse grain calls by bundling many requests into one call? What if I would like to allow clients to pipe these bundles request together. And what is the difference between the buzz phrase "Javascript on Demand (JoD)" and all that other JS that I just fetched from the web. ( )

After creating a significant number of web services, I've come to appreciate standards that more closely resemble the web.

Any time I have to use XML-RPC, I have to use libraries that are (at best) not totally standardized. Unlike HTTP, HTML, and JSON which are much closer to a working consensus. ( )

The interesting part is the beginning clearly defining what's exactly a RESTful services. Some good points expressed regarding the simplicity of HTTP (the genius part of HTTP). The rest of the book is for the Ruby fan... ( )

Interesting, but sloppy. ~100 pages in and it seems that every other page has an error or typo or contradiction or some other oddity.

I tend to trust the authors to get the essential concepts right, but the editing and tech review was so half-assed that the results are distracting. ( )