REST 控制器 class 对象的删除方法 responseType 为空

Question

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

@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;
}

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

NOT FOUND (404)：通常我们将它用于 URI/URL not found 但这里 URL/URI 是正确的，仅请求我的内容（电影 ID）不在数据库中。
我看到 NOT FOUND(404) 在许多示例中使用，即使没有内容匹配。
在这个404中是正确的选项那么什么时候使用204（无内容）？

所以谁能给我清楚的图片

Answer 1

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

毕竟 404 是一个客户端错误，指定客户端引用的资源也找不到，但请求本身是有效的。

204表示服务器成功处理请求但没有返回任何内容。但是，由于从未找到该资源，因此未成功删除该资源。所以204不适用。

Answer 2

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);
    }
}

Answer 3

I have confused lot what should be response code if Movie Object Not Found while delete a movie

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

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

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

幂等性，非常粗略地说，是指在传递同一消息的多个副本时，合规服务器仅限于做合理的事情。这不足为奇；删除两次与删除一次相同。

Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them to keep their contents up to date.

A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.

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

An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).

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

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

所以发回 200 Yup we deleted the movie 或 204 No Content 在我看来都是好的选项。（注意：204 并不意味着资源没有内容；它意味着 HTTP 响应具有 0 字节长的消息正文）。

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

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

REST 控制器 class 对象的删除方法 responseType 为空

REST Controller class delete method responseType for object is null

rest

spring

controller

http-status-codes