I\'m seeing many frameworks recently that have decided to \"fake\" PUT and DELETE requests. Like Ruby on Rails. They seem to be waiting for browsers to catch up. Are they waitin
Browsers do support PUT
and DELETE
, but it's HTML that doesn't.
For example, a browser will initiate a PUT
request via Javascript (AJAX), but not via HTML <form>
submission.
This is because HTML 4.01 and the final W3C HTML 5.0 spec both say that the only HTTP methods that their form
elements should allow are GET and POST.
There was much discussion about this during the development of HTML 5, and at one point they got added to HTML 5, only to be removed again. The reason the additional methods were removed from the HTML 5 spec is because HTML 4-level browsers could never support them (not being part of HTML at the time they were made); and there is no way to allow them to do so without a JavaScript shim; thus, you may as well use AJAX.
Web pages trying to use forms with method="PUT"
or method="DELETE"
would fall back to the default method, GET
for all current browsers. This breaks the web applications' attempts to use appropriate methods in HTML forms for the intended action, and ends up giving a worse result — GET
being used to delete things! (hello crawler. oh, whoops! there goes my database)
Changing the default method for HTML <form>
elements to POST
would help (IMO the default should have always been POST
, ever since Moasic* debuted forms in 1993), but to change the default would take at least a decade to percolate through the installed base. So in two words: ‘because legacy’. :-(
To support current browsers, authors will have to fake it with an override. I recommend authors use the widely knowna, b _method
argument by including <input type=hidden name=_method value=DELETE>
in their HTML; switch the form method to POST
(since the request is unsafe); then add recognition of _method
on the server side, which should then do whatever's necessary to mutate the request and forward it on as if it were a real DELETE request.
Note also that, since web browsers are the ultimate HATEOAS client, they need to have a new state to be transferred to them for DELETE requests. existing APIs often return 204 No Content
for such requests. You should instead send back a hypermedia response with links so that the user can progress their browser state.
Also see the answers to these similar/identical questions:
<img src=…>
tag — it should have been <image source=…>fallback</image>
.