如果我的网络服务允许客户使用 POST 请求执行删除,它是否仍被视为RESTful?
答案 0 :(得分:2)
严格来说,我认为事实并非如此,尽管我仍然认为它是RESTful的。有时候无法使用所有HTTP谓词,这会导致许多REST API通过POST或GET允许其他操作。
答案 1 :(得分:2)
我认为问题不应该是API是否“RESTful”,因为它已经成为一个流行语。一个更重要的问题是,这是否是对RFC 2616中定义的HTTP协议的良好使用。以下是相关部分:http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html。
它说“POST方法用于请求源服务器接受请求中包含的实体作为请求行中Request-URI标识的资源的新下级。” POST通常用于在集合中创建新项目或注释现有资源。虽然通过删除它来注释某些内容实际上并未被禁止,并且不存在违反安全性和幂等性的问题,但在POST上执行删除操作时并未按预期使用HTTP。
也就是说,如果您通过在资源中“设置删除标志”来修改和修改现有资源,那么您将遵循现代RESTful API实践。但完全打击它?不,这就是HTTP DELETE的用途。
答案 2 :(得分:0)
由于没有正式的RESTful标准,只要方法'覆盖'在参数中显式传递,例如method = DELETE就可以了。
答案 3 :(得分:0)
简短的回答是否定的,尽管从实际的角度来看,客户可能更容易实施,特别是如果他们不简单并且不知道如何进行删除。
据说,这是您的网络服务,因此您应该做最符合您业务需求的事情。完整的REST实现远不如关于如何操作API的优秀客户端文档重要。
答案 4 :(得分:0)
不,它不像HTTP那样是RESTful的。允许不支持DELETE或PUT的客户端与旨在支持它们的资源交互的方法是使用指示要执行的操作的自定义标头。然后在框架中有一个图层检查该标头并在资源代码中调用正确的方法。我见过最常用的方法是使用名为X-HTTP-Method-Override的标头。如果客户端无法操作HTTP标头,则可以将相同的方法(使用相同名称的事件)与请求参数一起使用。