Is Django admin's "delete confirmation" considered RESTful?
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.
Re: Is Django admin's "delete confirmation" considered RESTful?
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 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.
Re: Is Django admin's "delete confirmation" considered RESTful?
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" 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 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 mo
Re: Is Django admin's "delete confirmation" considered RESTful?
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 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/userto 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 urlwww.example.com://admin/auth/useris 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" > > 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 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 (a
Re: Is Django admin's "delete confirmation" considered RESTful?
Thanks Euan - I think that clarifies things. Thanks very much for your responses! Margie On Jul 7, 8:50 am, "euan.godd...@googlemail.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 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" > > > 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 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
Re: Is Django admin's "delete confirmation" considered RESTful?
I did not read the sources of the admin module devoted to deleting an
item, but I think the problem is not in the admin interface but in
html forms.
Html forms allow only GET and POST, but no DELETE and PUT. Given the
REST common-sense rule "whenever you POST, ask the user" the admin
interface - a web, html interface - behaves properly: a destructive
post checks the user's will.
On the other side, when we will have XForms 1.1 and Xhtml 2.0 we'll be
able to issue PUT and DELETE without the need for AJAX support:
var request = new XMLHttpRequest();
request.open("DELETE", "http://yoururl/page.html";, True);
If you want to REST-ise your app, you could have a look at piston:
http://bitbucket.org/jespern/django-piston/wiki/Home
On Wed, Jul 7, 2010 at 17:10, Margie Roginski 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
> 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"
> 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 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 t
