Comment by mg
3 months ago
GET because that is also the default for all other elements I think. form, a, img, iframe, video...
Ok, but what is the advantage to be "clear at the http level"?
3 months ago
GET because that is also the default for all other elements I think. form, a, img, iframe, video...
Ok, but what is the advantage to be "clear at the http level"?
GET shouldn't be used for a delete action, because it's specified as a safe method[0], which means essentially read-only. On a practical level, clients (like browsers) are free to cache and retry GET requests, which could lead to deletes not occurring or occurring when not desired.
[0] https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1
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.
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.
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.
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.
Well, its correct, so its likely to be optimized correctly, to aid in debugging, to make testing easier and clearer, and generally just to be correct.
Correctness is very rarely a bad goal to have.
Also, of course, different methods have different rules, which you know as an SE. For example, PUT, UPDATE and DELETE have very different semantics in terms of repeatability of requests, for example.
GETs have no side effects, by specification. DELETEs can have side effects.