Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
"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
"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
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
up vote 13 down vote accepted

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!

share|improve this answer
@Dean Aha, great example! Thanks :) – morganpdx Mar 9 '11 at 23:14
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
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

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.

share|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!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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