Outraged by Terrible Tech Book

I have now read two O’Reilly books that read more like fundamentalist religious texts than tech books. I read these books in hopes of picking up new skill sets. I want to get an honest assessment of a technology, its strengths and weaknesses. I want to learn about the gotchas before I discover them on my own. Many technologies get bad reputations not because they are bad, but because they are so easy to use badly.

Maven: The Definitive Guide was 400+ pages of what seemed like a lot of sad Ant bashing. I should have guessed from the cover. Nothing that mean spirited since IBM named the Eclipse project. RESTful Web Services was far worse though. At least Maven showed me how to use Maven. RESTful 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.

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 want a method that works on multiple types of resources. Like I want to call http://www.something.com/share?file=GUID or /share?contact=GUID. Share isn’t really a resource. REST would have me http://www.something.com/{type}/{guid}/share. In OO, you have a lot of common methods for objects, like toString(). So instead of having a /toString URI that takes different resources as args, I should have various resources that I can invoke GET toString() on. Just thinking about implementing things like this either leaves me with a mess of URI mapping for the sake of being pure, or an implementation like flickr, google, amazon, or del.icio.us.

What if I my resources are not always located by simple IDs  I have http://w.s.com/share?file=GUID and  http://w.s.com/share?parentfile=GUID&filename=this.txt. Both would do the same action. I am referring to the same file via a query and via GUID. I would much rather pass in some sort of locator object with fields. I would love to have the option to post a JSON object to /share.

Once you get past the simple examples from the book, you hit serious questions. The book doesn’t prepare you for the non-trivial web, nor does it give you a good idea if REST is either; but, their lack of real worl examples that match their definition of truely RESTful offers a hint.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s