我最近看到许多框架决定在表单提交(而不是 ajax)中“伪造” PUT 和 DELETE 请求。就像 Ruby on Rails 一样。他们似乎在等待浏览器赶上来。他们是在徒劳地等待吗?
这甚至计划在任何地方实施吗?
浏览器确实支持PUT
and DELETE
,但HTML不支持。
例如,浏览器将PUT
通过 Javascript (AJAX) 发起请求,而不是通过 HTML<form>
提交。
这是因为 HTML 4.01 和最终的 W3C HTML 5.0 规范都说它们的form
元素应该允许的唯一 HTTP 方法是 GET 和 POST。
在 HTML 5 的开发过程中对此进行了很多讨论,有一次它们被添加到 HTML 5 中,但又被删除了。从 HTML 5 规范中删除附加方法的原因是因为 HTML 4 级浏览器永远无法支持它们(在它们被制作时不是 HTML 的一部分);如果没有 JavaScript shim,就无法让他们这样做;因此,您不妨使用 AJAX。
对于所有当前浏览器method="PUT"
,尝试使用表单或method="DELETE"
将回退到默认方法的GET
网页。这破坏了 Web 应用程序在 HTML 表单中使用适当方法来执行预期操作的尝试,并最终给出更糟糕的结果 - <code>GET 被用于删除内容!(你好爬虫。哦,哎呀!我的数据库去了)
<form>
将 HTML元素的默认方法更改为POST
会有所帮助(自 1993 年 Moasic* 首次推出表单以来,IMO 的默认值应该一直是POST
),但更改默认值至少需要十年时间才能渗透到已安装的基础上。所以用两个词:'因为遗产'。:-(
为了支持当前的浏览器,作者将不得不使用覆盖来伪造它。我建议作者通过包含在他们的 HTML 中来使用广为人知的 a、b _method
参数;<input type=hidden name=_method value=DELETE>
将表单方法切换到POST
(因为请求不安全);然后在服务器端添加识别,_method
然后它应该做任何必要的事情来改变请求并将其转发,就好像它是一个真正的 DELETE 请求一样。
另请注意,由于 Web 浏览器是最终的HATEOAS客户端,因此它们需要有一个新状态才能传输给它们以用于 DELETE 请求。现有的 API 通常会204 No Content
针对此类请求返回。相反,您应该发回带有链接的超媒体响应,以便用户可以改进他们的浏览器状态。
另请参阅这些类似/相同问题的答案:
<img src=…>
标签的复合错误——它应该是<image source=…>fallback</image>
.