On Mon, Apr 15, 2013 at 6:32 PM, Russell Keith-Magee < [email protected]> wrote:
> > On Tue, Apr 16, 2013 at 6:12 AM, Brantley Harris <[email protected]>wrote: > >> Alex, I see http methods as being very basic, a part of the URL itself. >> In other words, from the level of the web framework it's pointless to talk >> about the URL as anything but a pair of request method and path. > > > I couldn't disagree more on this. URLs and HTTP Methods are completely > different things. They're even covered by different RFCs. No part of the > URL spec includes mention of the the HTTP method. The HTTP method is part > of a protocol for modifying resources identified by a URL. > > A URL describes a resource. It describes a "thing" that can have "stuff" > done to it. That's why HTTP methods like GET/PUT/POST/DELETE are sometimes > called "verbs" - they're "doing" words, describing what you're going to > "do" to a resource. GET me the resource. PUT a new resource. DELETE the > current resource. > > The dispatch process is - and should be - a two phase process: > > 1) Decide which resource is affected > 2) Determine how to handle the request that you've received. > > So you want to have different behaviour for different verbs? Fine - then > you put that at level 2. Yes, there's going to be a repeated pattern here, > so you'd be well served to have some sort of framework to support this -- > which is what the CBV base class is. If you don't like CBVs, feel free to > propose something else - but don't try and confuse the task of identifying > a resource with the task of correctly handling a request for a resource. > Yes we can write a dispatcher that doesn't care about the verbs. Wait, that's what we've already got. Surely I wasn't being literal when I said that the http methods were a part of the url, I meant from the standpoint of dispatching a request. I don't like CBV's. I have proposed something else. It's a simple keyword argument to url() that solves half of what CBV's are trying to solve without completely changing the layout of a project to favor needlessly complicated mini-frameworks of inheritance as opposed to simple composition with functions. > > To bring it back to your original example: > > > url('^objects/$', 'views.create_object', methods=['post', 'put'], > name='create_object'), > > url('^objects/$', 'views.get_objects', name='list_objects'), > > I completely fail to see the point of having different reverse endpoints > for these two. At the end of the day, both of them reverse to the same URL > - '/objects/'. Your proposed usage is presumably something like: > > requests.get(reverse('list_objects')) > requests.post(reverse('create_object'), data) > > However, to drive home the point that the verb *isn't* part of the URL, > the following would also work: > > requests.get(reverse('create_objects')) > requests.post(reverse('list_objects'), data) > > That is, you can POST to your "GET" url, and GET from your "POST" URL, and > you'd *get no error whatsoever*. So… what exactly is the point of having > different URL names? > Views are not resources. The urls.py file maps from the URL/HTTP/REST world into the world of python functions. When you name your views, you're doing that, naming your views. You are not naming URL resources. In fact, the whole point of reverse() is so that you can change your URLs without having to touch the rest of your code because you have been referring to the view. A simple example would be going from this: > url('^objects/$', 'views.create_object', methods=['post', 'put'], name='create_object'), > url('^objects/$', 'views.get_objects', name='list_objects'), To this, because you need to match an existing url pattern: > url('^objects/create/$', 'views.create_object', methods=['post', 'put'], name='create_object'), > url('^objects/all/$', 'views.get_objects', name='list_objects'), Now, you can see I don't have to change the rest of my code, I can merely continue on. This isn't just random simplicity, it uncovers the inherit nature of these abstractions. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
