To be fair, RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only. Even the ones that use POST aren't usually RESTful if it's something like a form submission, so Django's way is the path of least resistance.
RESTfulness is only really desirable in an API. I wouldn't want each one of my views to be in a class, because most views are GET-only
REST doesn't mean each of your views is in a class and being GET-only doesn't mean something isn't RESTful. I'm not sure I understand your reasoning.
Even the ones that use POST aren't usually RESTful if it's something like a form submission
It doesn't have to be that way. The path of least resistance is something that the framework determines. In many web-frameworks, the path of least resistance is to do everything (the default web dispatch) in a REST-ful style because that's the way the framework leans.
The framework itself is perfectly capable of supporting REST as the article we are discussing is evidence.
My point is that the default routing, the built-in helper functions, and the documentation for beginners all discourage it. For example, the router does not route differently based on the HTTP method. It only takes the URL into account and leaves it to the developer to make a switch based on if the method is GET or POST. This means you're effectively doing some of the routing in the urls.py and some of the routing inside your view.
Several of these REST frameworks above (for example the dagny project I mentioned) change that. I think REST is a good enough design pattern that the framework should lean heavily toward it by default.
My main site is django so I appreciate the flexibility I get from it. I think it should be possible to do non-REST. This is one thing that I struggled with as a new user. I thought Django would lead me down the right path and in my opinion the default routing is weak.
For our RESTful API, I use this:
http://djangosnippets.org/snippets/1071/