我有一个可以删除资源的API（删除/ resources / {resourceId}）
以上API只能告诉我们删除资源。现在，我想将API扩展到其他用例，例如在删除或删除该资源的其他相关资源之前进行该资源的备份等。 我想将删除API扩展到此（DELETE / resources / {resourceId}？backupBeforeDelete = true ...）
上述扩展API是否良好/推荐？
答案 0 :(得分：1)
根据HTTP Specification，任何HTTP消息都可以带有可选的正文和/或标题部分，这意味着您可以在后端控制-做什么（例如，查看服务器收到的内容和通常使用您的操作）（如果使用任何HTTP方法）；但是，如果您谈论的是RESTful API设计，DELETE或任何其他操作，则应引用REST API端点资源，该资源已映射到控制器的DELETE方法，然后服务器应根据中的逻辑执行操作。您的方法。
DELETE /resources/{resourceId} HTTP/1.1
应该可以。
答案 1 :(得分：0)
上述扩展API是否良好/推荐？
可能不是。
HTTP是（除其他事项外）关于消息语义的协议：关于消息 mean 的统一协议。
基本目标是，由于每个人对消息的含义都有相同的了解，因此我们可以使用很多通用组件（浏览器，反向代理等）。
当我们开始尝试以非标准方式整理消息时，我们会失去通用接口的好处。
就DELETE而言，您的用例遇到了一个问题，即HTTP没有定义参数化 DELETE。
在HTTP消息中放置参数的通常位置是消息正文内。不幸的是...
DELETE请求消息中的有效负载没有定义的语义；在DELETE请求上发送有效内容正文可能会导致某些现有实现拒绝该请求
换句话说，您不能指望通用组件在这里做正确的事，因为请求主体超出了范围。
另一方面
DELETE /resources/{resourceId}?backupBeforeDelete=true
这具有一个问题，通用组件将无法识别/resources/{resourceId}?backupBeforeDelete=true与/resources/{resourceId}是相同资源。两者的标识符不同，发送给一个用户的消息不会影响另一个。
对于您的用例，正确的答案是更改方法令牌；正确的标准方法是POST
POST在HTTP中有许多有用的用途，包括“此操作不值得标准化”的一般用途。 -Fielding, 2009
您应该对资源使用“真实” URI（在GET请求中使用相同的URI），并将所需的任何参数粘贴到有效负载中。
POST /resources/{resourceId}
backupBeforeDelete=true
假设您将POST用于其他“不值得标准化”的操作，则请求中将需要有足够的上下文，以便服务器可以区分不同的用例。在网络上，我们通常会通过HTML表单收集参数，通常的答案是在正文中包含请求令牌
POST /resources/{resourceId}
action=delete&backupBeforeDelete=true
另一方面，如果您认为正在进行的 值得标准化的操作，那么正确的做法是使用所需的语义定义一个新的方法令牌，并推动采用
MAGIC_NEW_DELETE /resources/{resourceId}
backupBeforeDelete=true
毕竟，这是PATCH的来源； Dusseault等人认识到修补程序语义对于所有资源都可能有用，创建了一个描述其所需语义的文档，并通过标准化过程来扩展该文档。