Ian Bicking: the old part of his blog

Re: HTTP verb distaste

I always seem to find interesting blog posts by you long after you wrote them ;)

Some time I'm going to take another shot at nailing this whole MVC "vs." REST thing (which is to me far more interesting than REST vs. SOAP) - tried and failed once already here: http://www.sitepoint.com/blogs/2005/12/22/mvc-and-web-apps-oil-and-water/

What I was grasping for in "Who GETs REST?" (http://www.sitepoint.com/blogs/2005/11/22/who-gets-rest/) is a single rule / guideline people could use, from which a whole bunch of other consequences naturally fall out, without having to be able to grasp the whole of REST. But think that failed.

The real point is I think that 99% of today's web frameworks put you through loops as a developer are either just horrible or dangerous. By contrast, if we had an API which relates directly the REST, my guess is the whole web dev thing gets alot easier for real people to grasp - it would be natural even if you don't know much about HTTP.

Looking at what we've got today...

Considering struts - it's amazing that people are willing to accept that kind of API. The concepts struts pushes you to think in terms of (Actions, ActionMappers blah blah) have _zero_ relationship to the medium - HTTP. Struts becomes some kind of Zen excercise of thinking in 13 dimensions. There's only an artificial correspondance between URLs and code you're writing. And somehow the idea that a framework constrains how you use URLs is deeply wrong.

Meanwhile the Rails / Catalyst / Django / Turbogears approach - URLs to class methods has inverted the problem - it's almost too easy. Relateing URLs to class methods means people are "tunneling" all kinds of verbs through HTTP GET (delete/list/index/show/find/findByName etc. etc.) - and from there we have the whole "Goodnight Moon" factor (Mark Pilgrim, as a new father, being very dry - http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters#c1115432785)

Perhaps the acid test is "how easy is it to implement conditional HTTP GET's"? This point doesn't travel so well, which is a shame - it's another "rule to illustrate the point" rather than a mere feature request. In both the above two MVC framework styles, doing any kind of HTTP caching is code you're going to have to tack on as a (very) painful after-thought.

To me the obvious "right path" is mapping URLs / resources to classes, which have methods corresponding to HTTP methods - then you get to have a property "last_modified" and your framework can handle the HTTP caching for you automatically.

Of the REST frameworks out there, web.py has the API right but is still being too light weight to provide "off the shelf" resources, which would help. There's also tonic (PHP) http://tonic.sourceforge.net/ which seems to be getting some of the fundamental ideas right, but needs to be more than a one-developer code base. Then there's RESTLET (http://www.restlet.org/) which looks promising but, in usual Java style, it's embraced choice (e.g. server container support) as a path to wasting my time. Also Rails finally seems to be heading this way (http://jimonwebgames.com/articles/2006/06/26/dont-say-crud-say-fucd) without complete submission though on the new method names. But no one seems to be _really_ there yet.

And in fact it's not really MVC vs. REST. The value of MVC-style seperation or concerns goes without saying but the problem is people tend to consider MVC as open season to inventing a ton of verbs for their application, but with HTTP the verbs are already fixed (and emphasize coarse grained APIs) - the nouns are where you get to have a choice - not a natural consequence of MVC.

At a fundamental level, the whole thing is kind of bizarre - it's taken this long for people to figure out how to write code to such a simple and widely used protocol (even if it is only half-implemented). It's like on the one hand we've got the "who gives a sh*t" crowd, hacking away with stuff like PHP, oblivious until someone tells them something else is cool while on the other we've got the "I love complexity" crowd, happy to buy obscure (typically Java) abstractions to flagellate themselves with, never questioning whether it's a good idea or not.


Comment on HTTP verb distaste
by Harry Fuecks