我有一个可以删除资源的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等人认识到修补程序语义对于所有资源都可能有用,创建了一个描述其所需语义的文档,并通过标准化过程来扩展该文档。