很奇怪的http delete rest操作-delete with a lot parameters

Question

分析团队制定了一些我觉得有点奇怪的规范。

我必须删除数据库中的资源 table。我有 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 with REQUEST BODY 感到愤怒。

我必须切换到

POST 对 REQUEST BODY 的操作
使用一些请求参数进行删除操作

开发团队喜欢在 RESTful 环境中呆得越久越好。怎样才不会走调？

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

Answer 1

Swagger generation gets angry about DELETE with REQUEST BODY.

是的，没错。

A payload within a DELETE request message has no defined semantics -- RFC 7231

DELETE 是关于将 URI 与其表示分离。这有点类似于从文件系统中的 map/dictionary 或符号 link 中删除密钥。它告诉网络服务器停止为特定网页提供服务。

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

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

注意标准中包含的此观察结果：

Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect.

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

记住：it is okay to use POST. The world wide web was catastrophically successful using little more than GET and POST.

They want to add as input parameters some other values, present in the rekord, because, they say "the delete operation is very delicate in this case and we want to be sure to exclude errors in frontend, the id passed is should be the id of the values of the rekord passed".

这里可能正在寻找的是 conditional delete. We have standardized headers that can be used by validators 以确定 DELETE 请求和资源的当前状态是否“匹配”。

很奇怪的http delete rest操作-delete with a lot parameters

Very strange http delete rest operation - delete with a lot parameters

rest

http

uri

restful-url

httpverbs