[JimDabell]

That means I can make you delete things by embedding that delete URL as the source of an image on a page you visit.

GET is defined to be safe by HTTP. There have been decades of software development that have happened with the understanding that GETs can take place without user approval. To abuse GET for unsafe actions like deleting things is a huge problem.

This has already happened before in big ways. 37Signals built a bunch of things this way and then the Google Web Accelerator came along, prefetching links, and their customers suffered data loss.

When they were told they were abusing HTTP, they ignored it and tried to detect GWA instead of fixing their bug. Same thing happened again, more things deleted because GET was misused.

GET is safe by definition. Don’t abuse it for unsafe actions.

[mg]

You can already do POST requests by embedding forms and/or JS. And with the proposed <button method=DELETE> you could also embed that. So I don't see how the proposal of adding more HTTP methods to html elements prevents abuse.

[williamdclt]

I think you're misunderstanding what your parent meant by "abuse".

In in this context it meant "misuse", there's no malicious actor involved. GET should have no side-effect which enables optimisation like prefetching or caching: they used it for an effectful operation (deletion) so prefetching caused a bug. It's the developers fault, for not respecting the guarantees expected from GET.

If they'd used POST, everything would have been fine. There's much less of an argument for using `POST /whatever/delete` rather than `DELETE /whatever`. At this point it's a debate on whether REST is a good fit or not for the application.

[masklinn]

It prevents "required" abuse of the HTTP protocol (having to pipeline everything via POST even though that's not its purpose), without the requirement of adding javascript to the page.