I agree on that it's not a good ideo to have actions in GET
parameters. For things like sorting, pagination and the like it's
propably a good idea because you are only changing the view on the
same data. But "add" is a completely new thing. In HTTP terms it
should propably be a PUT request to /products/, but that is currently
not possible with browsers.
I would also say that Aidas' option #6 is not the way to go because
having two separate trees (/products/ and /product/) would lead to
confusion. And it would be against the goal of decoupling of django
apps because you would have to put at least two lines in your root
URLconf when you should propably try to delegate the whole URL
handling to the URLconf of the app itself, like
(r'^products/(.*)$', include('products.urls')),
I did some research and found the following quotes related to that
topic:
"Use a 'gradual unfolding methodology' for exposing data to clients."
– http://www.xfront.com/tsld060.htm
"You'll know you've got a good URI design when it's easy to extend
hierarchies by tacking on additional path variables." – Richardson/
Ruby – RESTful Web Services, p118
I think there is no perfect solution to that problem you are dealing
with. I have used the /products/myproduct.123/ approach in the past
and it worked fine for me. So I would either go for that one or for
the prefix approach (/products/+add/) but probably with another prefix
as last.fm. Maybe an underscore _ but I'm not sure. Both are not
beautiful but not completely ugly as well.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
