Actually, the confirmation page is not accessed via a GET. Using the admin's auth model as an example: the user does a GET to something like www.example.com://admin/auth/user to get a list of users. Then they checkmark the users they want to delete, select the "delete" action, and then click on "go", which does a POST to ://admin/auth/ user. The server code for the post does a render_to_response and simply renders a delete confirmation page, resulting in the user seeing the delete confirmation. The url that the user sees with this delete confirmation is the same, //admin/auth/user. From the delete confirmation page, the users clicks "Yes I'm Sure" and this does another post to ://admin/auth/user. On the server side the code detects the "Yes I'm Sure" input and does its thing (deletes the selected uesrs), and then redirects back to ://admin/auth/user. This redirect is a GET, so it now displays the list of users, again at :// admin/auth/user.
It seems that that url www.example.com://admin/auth/user is getting used for one GET and two POSTS. My question is pretty much: Is this a good way to do this? Is it ok to have different pages (ie the user list and the user delete confirmation) all show up with the same url? If there is some better way, what is it? Hypothesizing on other ways: when the server side does the render_to_response to display the delete confirmation, should it be replacing the url that the user sees? IE, instead of showing ://admin/auth/user, show ://admin/auth/ user_delete_confirmation? And if so, how does one do this? I don't think you can replace the url with render_to_response, right? I could do a redirect, but if I did that, I would have to save the ids of the users being deleted (in the session I guess). Margie On Jul 7, 3:00 am, "euan.godd...@googlemail.com" <euan.godd...@gmail.com> wrote: > I'm not entirely sure whether you're asking one question or two here. > > Firstly, I think that in the RESTful sense, there's nothing wrong with > having a confirmation page that uses the same URL to perform an action > *providing* the HTTP verb is different. In this case the confirmation > page is accessed via a GET (I assume) and the actual delete is > performed via a POST. > > I guess that strictly speaking to be truly RESTful, the view should be > using the DELETE verb. However, since some browsers don't support > DELETE and PUT, most web apps use just GET and POST. > > I'm not sure whether that answers your question, but hopefully clears > it up a bit. > > Euan > > On Jul 7, 2:49 am, Margie Roginski <margierogin...@yahoo.com> wrote: > > > I have an app that is modeled after the django admin app. In general > > it seems to me that the admin app is RESTful. However, I am > > encountering a situation that is similar to the admin apps delete > > confirmation process, and I'm curious if anyone out there could > > comment on whether this particular part is considered "RESTful", or if > > not "RESful", I guess I'd just like opinions on if it's a good way to > > do things. Let me describe my question more. > > > In the django admin, you can click on a bunch of objects and then > > select the "delete" action, and then click "go". This takes you to a > > delete confirmation page that asks if you are sure. You can click > > "I'm sure" to proceed with your delete. This delete confirmation page > > has the same url as the objects changelist page. And that's the core > > of my question - is that a good thing? > > > I have a situation that is quite similar, but a bit more complex. To > > give a hopefully simple analogy, suppose that the admin's delete > > confirmation page had an input field associated with each object, > > which required the user to put in a "reason" prior to clicking "I'm > > sure". And if the user doesn't put in a reason, imagine they should > > be presented with the same delete confirmation page, but with an error > > on the fields where no reason was supplied. Should this page also be > > at the same changlist url? > > > I *think* the answer to this question is yes (though perhaps it is not > > RESTful). My reason behind that is that if I create a different url, > > which is exposed to the user, then I would really need to make that > > URL "GETable". IE, the user should be able to type it in and have it > > be meaningful. However in the case of the admin delete (and in my app > > as well), the info on what we are going to delete is transient and > > can't be recreated through a new GET, so doing a GET on this new URL > > would have no purpose and would be confusing to the user. > > > I know there is no "right" answer here. I'm just looking for opinions > > from people who value well structured APIs. > > > Thanks for any insights! > > > Margie -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
