Comment by AndrewHampton

3 months ago

What HTTP method would you expect the second example to use? `GET /users/delete?id=354`?

The first has the advantage of being a little clearer at the HTTP level with `DELETE /users/354`.

8 comments

AndrewHampton

Reply
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"?

  • JimDabell  3 months ago

    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  3 months ago

      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.

      2 replies →

  • lionkor  3 months ago

    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.