Someone Save Us From REST

Crack me up.

I am still learning programming the hard way - namely, by checking out how other folks do it, then struggling to do it myself. However, I've learned enough, I think, to get the impression that some people get rrrreeeallly attached to their architecture.

I have come to believe that all these models, "patterns" and such are very useful tools, but only that. Seems like we keep having these religous wars about language, patterns, architecture, whatever.

All of it is only useful as long as it, well, useful. When the "architecture" starts hindering the function, it has stopped doing it's job.

I used to be a programmer like you, then I took a Paradigm to the ... sorry, I can't do it.

You raise very good points though are we asking to be saved from REST or REST Pedants who argue about minutia ?

I have not yet seen any application that would be improved by full HATEOAS. Fielding argues that you need it if you intend to be around for decades. Guess what, the Flickr API is verging on a decade and it's still doing fine.

Some things in the Flickr API could be nicer with more HATE. For instance, currently, the client needs to know how to turn a returned photo ID into a URL. Fielding would ask why the API doesn't just return URLs in the first place. (One answer: because that would be inanely repetitive.)

But that's mostly cosmetic. Yes, we expect the client to translate IDs to page URLs, but we also expect it to understand what the difference between a photo and a user is.

Nobody has explained to me how "Hypermedia" APIs are supposed to be traversable without a programmer embedding significant domain knowledge into the library anyway.

You're going to need a ControllerFactory for those Controller's; but at least you're using MVC. Did you remember to not have your Singleton instance instantiated until its first call?

Programming is an art as well as a science; and those papers were guides to direct us toward something useful, not to be followed as creed and memorized to be recited in a religious ceremony. The sooner people learn that, the better.

In all, I agree with your the post.

What, an methodology that encourages (pedants note: I did not say mandates) a CRUDdy API, where resources are grouped together behind different urls, making automated interactions of any significance an almost hilariously slow series of HTTP requests (oh, oh, oh, keep alive!) while at the same time giving the API designer a smug sense of satisfaction and accomplishment might be worth looking at skeptically?

Naaaaaaaaaah.

Nice explanation from Glenn on both implementation decisions - both separate controllers and different url's: http://codebetter.com/glennblock/2012/02/28/why-are-there-2-...

Brilliant post with intended humor. I see some bigger points here, beyond the discussion of REST. Like a satire on design and (over) engineering.

Awesome post. Love how Rob questions things and stirs the pot. Several good points.