Thanks Euan - I think that clarifies things. Thanks very much for your responses!
Margie On Jul 7, 8:50 am, "euan.godd...@googlemail.com" <euan.godd...@gmail.com> wrote: > I think in the strict REST sense, it would be best to POST to one URL > with the list of object IDs to delete to set this action up and then > redirect to another URL with a GET which asks for confirmation based > on the previous setup and then POSTs to delete. This keeps it RESTful > in the sense of one URL, one verb does one thing, but clearly relies > on an underlying mechanism to work properly. > > I'm not sure whether REST is designed for multi-step processes like > this. > > Euan > > On Jul 7, 4:10 pm, Margie Roginski <margierogin...@yahoo.com> wrote: > > > 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 > > likewww.example.com://admin/auth/usertoget 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 urlwww.example.com://admin/auth/userisgetting > > 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.
