When building a simple web app with database delete functionality, you normally would take the following steps:

  1. User initiates a GET request using a delete link
  2. User confirms the deletion
  3. Upon confirmation, browser initiates a POST request to the server to perform the deletion

What are the reasons for this convention? I understand that it sets up a confirmation step which would prevent automated calling of the delete function (as with spiders and such) - are there other reasons?

  • "Normally"? RESTful web services use GET, POST, PUT and DELETE. Please clarify what you mean when you say "normally". – S.Lott Mar 9 '11 at 22:58
  • 1
    "it sets up a confirmation step". Are you referring to the browser? All of this is a matter of convention. You can make your app respond to any command any way you'd like. And I don't think anything a browser does really "prevents hacking". – Mark Canlas Mar 9 '11 at 23:00
  • @S.Lott - I'm referring to a fairly simple web page - no web services used. AFAIK, that means GET or POST. – morganpdx Mar 9 '11 at 23:09
  • @Mark Yes, sorry if that wasn't clear. Using a GET - user response - POST format prevents automated, mass deletes, which I termed as one form of hacking. – morganpdx Mar 9 '11 at 23:10
  • 3
    Please update your question. It's your question. You own it. Adding comments to it is not helpful to others. update your question to contain all the facts. – S.Lott Mar 10 '11 at 0:09

By convention, GET requests are always assumed to be non-destructive. If you do destructive thing via a GET (not just deleting stuff, but also adding or changing content) then every time Google goes to index your site (and it does that by issuing GETs on all of your pages) and some of those GETs delete content, then you'd be deleting half your database every time your site was indexed.

I remember one story where a developer had written a script to crawl an internal intranet site. He left it running overnight and came back in the morning to discover that all photos that users had uploaded had been changed to some weird random picture somehow. Turns out, someone had allowed changing the photos via a GET request and his script had gone through every one of those on the whole intranet!

|improve this answer|||||
  • 1
    I think I've now come across at least three scenarios in my career where content has been deleted because of a crawler (Google or internal) following delete links. At least one of these was caused by a (then) widely used third party library. – HorusKol Mar 10 '11 at 2:24
  • 1
    I think the word you are looking for is idempotent rather than non-destructive, as defined by the W3C. I wouldn't really consider adding content to be "destructive". – Sedate Alien Mar 10 '11 at 2:35
  • +1fully agree with answer, but there is always some sort of security to protect any one to GET – Jigar Joshi Mar 10 '11 at 5:44
  • How does this change with Ajax links? Or are those ignored by most spiders, since it's not specifically a GET? – morganpdx Mar 10 '11 at 19:10
  • @morganpdx: it depends how you've implemented them. The crawlers don't run Javascript (mostly), so they're not going to "see" links which are only executed via Javascript. But I've also seen Ajax implemented such that a "regular" <a href> link is turned into an Ajax request by Javascript, in which case the crawler would see it. I would still be hesitant to do anything with side-effects via GET even using Ajax. You can do POST via Ajax just as easily (for the most part). – Dean Harding Mar 10 '11 at 23:37

There is never a situation where it's ok to initiate a Delete on a GET. It is very bad practice to use GET to modify or delete. See 9.1.1. of the HTTP spec, where it clearly states "the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval."

The DELETE method requests that the origin server delete the resource identified by the Request-URI.

So you could use either POST or DELETE, except that using DELETE isn't that common and is really designed to work with PUT.

|improve this answer|||||

One very good reason not to use a GET for deletion: there was a web site which worked great until the search engines crawled it, and clicked on all the links, including the "delete item" links. It took the developer a while to figure it out, then it took a while to get the handprint off his forehead!

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.