You are writing a comment about A Django Anti-Pattern, Rolling Your Own REST, here is a quick summary:
Almost every web project ends up with a little slice of REST to call its own. One of the great conveniences of working with Django is that it makes rolling these slices of REST very simple. Simple enough that we as a community are still haven't come up with a compelling unified REST solution. Hopefully we can refocus on this problem a bit with the new 1.0 roadmap, and have something really useful ready to go when Django 1.0 hits the newsstands.
You are responding to this comment written by Charlie on June 13th 2008, 12:39.
Hey, thanks for spending some cycles on this!
On the one hand, when I picked up the Django book recently, I recognized that it wouldn't be hard to create such an api given the regex URL routing.
On the other, I found myself annoyed by some Django ways of doing things.
For instance, a url gets routed to a view function, without regard for the HTTP method being used. So, it's left to that function to do some if tests or case statements or something to separate the different HTTP methods.
One idea I came up with is to define a "resource" class with some sort of base "handlerequest" function. This function would separate GETs, POSTs, PUTs etc out to separate get(), post(), put() methods.
Then you could subclass that for some kind of new resource you want to define, and not bother rewriting the handlerequest() function.
It'd be nice if we could mirror the model Rails has adopted: http://www.softiesonrails.com/2007/4/18/rest-101-part-4-routing
That way, with a minimum of effort, you could write an api for an app on either rails or django, and the same client code would work with either.
Please be aware that comment forms go stale after one hour.
Comments may make use of LifeFlow MarkDown. Raw html will be escaped.
Quick Introduction to LifeFlow MarkDown Syntax
A highlighted code block:
Other common languages work as well: scheme, python, java, html, etc.
Other markdown syntax: