如果在PUT期间没有提供对象，RESTful服务是否应该返回资源？

Question

我有一个带有PUT端点的REST API，如下所示：

api.website.net/resources/resourceId

此端点的控制器实现如下所示：

@RequestMapping("/resources/{resourceId}") public Resource putResource(@PathVariable(value = "resourceId") String resourceId, @RequestBody(required = false) Resource resource)

有用户可能会对此资源执行PUT，但忽略在正文中提供对象（即resource == null为真）。

以下哪种方法更加RESTful？

1. 在此端​​点上有PUT只返回现有的Resource对象而不做任何更改，或
2. 在请求正文中创建所需的对象吗？

请注意，在两种情况下，对象都存在。

Answer 1

根据我对PUT定义的解释，要求一个正文会更加RESTful，因为定义似乎意味着一个实体存在：

来自https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

  

9.6 PUT

     

PUT方法请求将所包含的实体存储在   提供了Request-URI。

表示＆＃34;封闭实体＆＃34;对我来说意味着一个实体确实存在。

我认为如果你PUT没有，它最终会与DELETE相同。这只是让我更加想到PUT应该需要一个正文，而DELETE应该用于该功能。

所有这一切，当然可以实现接受PUT请求而没有身体的东西，尽管正如我所说，我不认为这会是RESTful。

这里有一些关于这个主题的讨论：Is an HTTP PUT request required to include a body?

Answer 2

  

有用户可能会对此资源执行PUT，但忽略在正文中提供对象（即资源== null为真）。

趣。

PUT方法在HTTP / 1.0规范的appendix D中提到，包含在HTTP/1.1 specification中，目前在2014 HTTP / 1.1规范的content and semantics chapter内定义。

它的用例沿袭为page publishing，将请求中嵌入的表示形式写入服务器自己的商店。

没有有效负载的PUT请求类似于将空文件插入特定位置的请求。对于文件系统或键值存储来说，这是完全合理的事情。

  

以下哪种方法更具RESTful功能？

REST的适用约束是统一接口 - 此资源上的PUT应与Web上的其他任何位置具有与PUT相同的语义。因此，PUT处理是idempotent，并且成功的PUT creates/replaces具有由请求中的表示定义的状态的资源的状态是非常重要的。

  

在此端点上有一个PUT只返回现有的Resource对象而不做任何更改   在请求正文中创建所需的对象？

我认为其中的第二个更接近你想要的。您无法强制客户端向您发送资源的有效表示，但您可以拒绝任何未提供有效表示的请求。因此，如果您发现所提供的表示形式并不令人满意，那么您应该考虑400 Bad Request或409 Conflict。

注意：发送4xx响应时，您通常会发送问题的表示，而不是资源的表示。

  

除了在响应HEAD请求时，服务器应该发送一个包含错误情况说明的表示，以及它是暂时的还是永久的。

返回资源当前状态的副本对于告诉客户端出了什么问题并不有用。