对象的 REST 控制器类删除方法 responseType 为 null答案

【问题标题】：REST Controller class delete method responseType for object is null对象的 REST 控制器类删除方法 responseType 为 null
【发布时间】：2018-11-02 11:01:08
【问题描述】：

我的休息控制器类中有以下方法

@DeleteMapping("/delete/{id}")
public ResponseEntity<?> deleteMovieById(@PathVariable Integer id) {
    try {
        service.deleteMovieById(id);
        responseEntity = new ResponseEntity<String>("Movie Deleted", HttpStatus.OK);
    } catch (MovieNotFoundException e) {
        **//Confused over here**
    } catch (Exception e) {
        responseEntity = new ResponseEntity<String>("Unable delete movie", HttpStatus.INTERNAL_SERVER_ERROR);
    }
    return responseEntity;
}

如果删除电影时找不到电影对象，我很困惑应该是什么响应代码

未找到 (404)：通常我们将其用于未找到的 URI/URL，但此处 URL/URI 正确，仅请求我的内容（电影 ID），但不在数据库中。
我发现在许多示例中都使用了 NOT FOUND(404)，即使没有内容匹配。
在这个 404 中是正确的选择，那么什么时候使用 204（无内容）？

所以任何人都可以让我清楚地了解这些

【问题讨论】：

标签： spring rest controller http-status-codes

【解决方案1】：

我认为 404 绝对是正确的方法。客户端正在尝试对特定资源执行某些操作。在这种情况下删除它。当找不到资源并因此无法执行删除时，对我的唯一明确响应似乎是 404。

毕竟 404 是客户端错误，指定客户端引用的资源也无法找到，否则请求本身是有效的。

204 表示服务器成功处理请求但没有返回内容。但是，该资源未成功删除，因为它从未被发现。所以204不适用。

【讨论】：

【解决方案2】：

如果删除电影时找不到电影对象，我很困惑应该是什么响应代码

如果我们认为请求的目标uri中存在拼写错误，那么我认为404 Not Found是合适的，如果目标uri标识了不支持删除操作的资源，我认为405 Method Not Allowed。

如果 target-uri 的拼写正确，那么事情就会变得更有趣。

一个请求方法被认为是“幂等的”，如果预期的效果是使用该方法的多个相同请求的服务器是与单个此类请求的效果相同。请求方法本规范定义的 PUT、DELETE 和安全请求方法是幂等的。

幂等，粗略地说，意味着当传递同一消息的多个副本时，兼容的服务器仅限于做合理的事情。这应该不足为奇。删除两次与删除一次相同。

由于 PUT、POST 或 DELETE 等不安全的请求方法（[RFC7231] 的第 4.2.1 节）有可能改变源服务器上的状态，因此干预缓存可以使用它们来保持其内容最新。

当接收到非错误状态代码时，缓存必须使有效的请求 URI（[RFC7230] 的第 5.5 节）以及 Location 和 Content-Location 响应头字段（如果存在）中的 URI 无效响应不安全的请求方法。

这就是我们关心的原因——如果我们遵守规则，那么我们“免费”支持标准缓存语义；客户端可以使用任何现成的缓存，而不需要定制代码。

如果收到的 If-Match 条件评估为 false，则源服务器不得执行请求的方法；相反，如果源服务器已验证正在请求状态更改并且最终状态已经是反映在目标资源的当前状态（即，用户代理请求的更改已经成功，但用户代理可能不知道它，可能是因为先前的响应丢失或其他人进行了兼容的更改用户代理）。

因此，在条件 DELETE 的情况下，如果资源已被删除，我们显然可以发送 2xx 响应。

...而且我没有在规范中找到一个反对论点来建议不应该将相同的行为用于 unconditional 删除。它仍然是幂等的，资源的当前状态反映了预期的最终状态，缓存会做正确的事情。

所以发回200 Yup we deleted the movie 或204 No Content 在我看来都是很好选项。（注意：204 并不表示资源没有内容，而是表示 HTTP Response 有一个 0 字节长的消息体）。

这是否重要可能取决于缓存实现者如何解释RFC 7231 4.3.5——当接收到错误状态代码时缓存是否应该使其存储的表示无效？

但是，由于我们可以确定在 RFC 7234 兼容的缓存中，在给定非错误状态代码的情况下，它会做正确的事情，因此我更愿意在这种情况下使用它们。

【讨论】：

我喜欢详尽的答案！不过，我有一个问题，您能否区分 204 表示由于已被删除而未找到的资源和 404 表示根本不存在的资源？

【解决方案3】：

404（未找到）是在这些情况下的预期行为，因为找不到电影（用于删除）。好主意是为客户端添加适当的错误消息：

@DeleteMapping(path = "/users/{id}")
public void deleteUsers(@PathVariable Long id) {
    boolean success = service.delete(id);

    if(!success)
        throw new UserNotFoundException("User id = " + id);

}


@ResponseStatus(HttpStatus.NOT_FOUND)
public class UserNotFoundException extends RuntimeException {

    public UserNotFoundException(String message) {
        super(message);
    }
}

【讨论】：