代码之家  ›  专栏  ›  技术社区  ›  Sasikumar Murugesan

对象的REST控制器类delete方法responseType为空

  •  2
  • Sasikumar Murugesan  · 技术社区  · 7 年前

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

    如果删除一部电影时找不到电影对象,我就搞不清楚应该有什么响应码

    1. 找不到(404):通常我们用它来表示URI/URL找不到,但这里的URL/URI是正确的,只请求我的内容(电影id),不在数据库中。
    2. 我看到NOT FOUND(404)在许多示例中使用,即使没有内容匹配。

    有没有人能给我一个清晰的画面

    3 回复  |  直到 7 年前
        1
  •  4
  •   ophychius    7 年前

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

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

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

        2
  •  3
  •   VoiceOfUnreason    7 年前

    如果删除一部电影时找不到电影对象,我就搞不清楚应该有什么响应码

    404 Not Found 是适当的,或 405 Method Not Allowed 如果目标uri标识不支持删除操作的资源。

    具有该方法的多个相同请求的服务器是 与单个此类请求的效果相同。请求方法的 由本规范定义的PUT、DELETE和safe请求方法 是幂等的。

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

    无条件的 删除。它仍然是幂等的,资源的当前状态反映了预期的最终状态,缓存将做正确的事情。

    200 Yup we deleted the movie 或 204 No Content 在我看来都是 选项(注: 204

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

    但由于我们可以确定,在rfc7234兼容缓存将做正确的事情给予非错误状态代码,我更愿意使用他们在这种情况下。

        3
  •  1
  •   Vasily Komarov    7 年前

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