This is my experience: I have to rewrite administration page where
there is remove button (in a form) with only javascript confirm.
I thought: “no one had problem with no limitation in the past, why they
should now? I’ll use a link with javascript confirm.
It happened I have a dashboard page where is listed the last entries
and links for update and delete its. It happened that few day later 20
entries was deleted and I was looking for what caused the problem for
one day.
I supposed no one would be so silly to click on delete for 20 times
… but wait there are exactly the number of displayed entries in
dashboard: 20 entries.
Elementary my dear Watson: when user could not make a mistake, a tool
can help him .. a SEO Tool.
Yes, the thing you use to check if there is a broken link, actually
visit the link and do not care about javascript limiting action on
click, it just … delete.
RESTful paradigm require DELETE http request for delete action, it
could be replaced with a POST, but anyway never a GET should have
action of DELETE (neither create, nor update). And this is a rule of
thumb everywhere http is used as documented in rfc.
Idempotent methods: have the same result and do not change URI [GET, HEAD]
Non-idempotent methods: could have different result based on data and
could change resource [POST,PUT,DELETE]
That’s why the names safe and unsafe methods:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html