很奇怪的http删除休息操作——删除参数很多答案

【问题标题】：Very strange http delete rest operation - delete with a lot parameters很奇怪的http删除休息操作——删除参数很多
【发布时间】：2021-07-26 17:47:10
【问题描述】：

分析团队制定了一些对我来说听起来有点奇怪的规范。

我必须删除数据库表上的资源。我有 rekord 的 id 作为输入参数。

这是直接的 http 删除操作。

DELETE http://my-url/{id}

他们想添加一些其他值作为输入参数，存在于 rekord 中，因为，他们说“在这种情况下删除操作非常微妙，我们希望确保排除前端的错误，传递的 id 应该是传递的 rekord 值的 id”。

关于这个要求有很多内部讨论。菜肴在参与者之间飞来飞去。无论如何，我们必须满足它。

我知道这不是更多的 RESTful 操作。

我是这样修改的：

DELETE http://my-url/{id}
REQEUST BODY
{
    "myProperty1" = 123,
    "myProperty2" = "VALUE",
    ...
}

Swagger 一代对 DELETE 和 REQUEST BODY 感到愤怒。

我必须切换到

开发团队喜欢尽可能长时间地呆在 RESTful 环境中。怎样才能不走调？

我们认为不会受到赞赏的任何其他建议或解决方案。

【问题讨论】：

【解决方案1】：

Swagger 一代对 DELETE 和 REQUEST BODY 感到愤怒。

是的，没错。

DELETE 请求消息中的有效负载没有定义的语义 -- RFC 7231

DELETE 是关于将 URI 与其表示分离。这有点类似于从地图/字典中删除键或文件系统中的符号链接。它告诉网络服务器停止提供特定网页。

通常很容易弄清楚 DELETE 请求的标识符应该是什么；它将与您用于通过 GET 请求查找表示的标识符相同。

DELETE 是在transfer of documents over a network 域中具有语义的操作。

请注意标准中包含的这一观察：

相对较少的资源允许使用 DELETE 方法——它的主要用途是远程创作环境，用户对其效果有一定的指导。

如果您尝试做的是向您的服务器传递一个带有有效负载的消息，以便服务器可以做一些聪明的事情，您可能应该使用 POST，而不是 DELETE。

记住：it is okay to use POST。使用little more than GET and POST，万维网取得了灾难性的成功。

他们想添加一些其他值作为输入参数，存在于 rekord 中，因为，他们说“在这种情况下删除操作非常微妙，我们希望确保排除前端的错误，传递的 id 应该是传递的 rekord 值的 id”。

这里正在寻找的可能是conditional 删除。我们有标准化的标头，validators 可以使用这些标头来确定 DELETE 请求和资源的当前状态是否“匹配”。

【讨论】：