REST Controller класс метод удаления responseType для объекта равен нулю

Question

У меня есть метод ниже в моем классе контроллера отдыха

@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. В этом 404 правильный вариант тогда, когда использовать 204 (без содержимого)?

Итак, кто-нибудь даст мне ясную картину об этих

Answer 1

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 2

Я запутал много, каким должен быть код ответа, если объект фильма не найден при удалении фильма

Если мы считаем, что в target-uri запроса есть ошибка орфографии, то я думаю, что 404 Not Found является подходящим, или 405 Method Not Allowed, если целевой uri идентифицирует ресурс, где операция удаления не поддерживается.

Если написание target-uri правильное, то все становится более интересным.

Метод запроса считается «идемпотентным», если предполагаемый эффект на сервер нескольких идентичных запросов с этим методом является так же, как эффект для одного такого запроса. Из методов запроса определяется этой спецификацией, PUT, DELETE и безопасными методами запроса идемпотентны.

Идемпотент, очень грубо, означает, что совместимый сервер ограничен в выполнении разумных действий при доставке нескольких копий одного и того же сообщения. Это не должно быть сюрпризом; удаление чего-либо дважды аналогично удалению чего-либо один раз.

Поскольку небезопасные методы запроса (раздел 4.2.1 [RFC7231]), такие как PUT, POST или DELETE, могут изменять состояние на исходном сервере, промежуточные кэши могут использовать их для обновления своего содержимого.

Кэш ДОЛЖЕН сделать недействительным действующий URI запроса (раздел 5.5 [RFC7230]), а также URI в полях заголовка ответа Location и Content-Location (если имеется) при получении кода состояния без ошибок в ответ на небезопасный метод запроса.

И именно поэтому мы заботимся - если мы играем по правилам, то мы поддерживаем стандартную семантику кеша «бесплатно»; клиенты могут использовать любой готовый кеш, не требуя специального кода.

Исходный сервер НЕ ДОЛЖЕН выполнять запрошенный метод, если полученное условие If-Match оценивается как ложное; вместо этого сервер происхождения ДОЛЖЕН ответить либо а) кодом состояния 412 (Не выполнено предварительное условие), либо б) одним из кодов состояния 2xx (Успешно), если сервер источника подтвердил, что запрашивается изменение состояния, а окончательное состояние уже отражено в текущем состоянии целевого ресурса (т. е. изменение, запрошенное пользовательским агентом, уже успешно выполнено, но пользовательский агент может не знать об этом, возможно, из-за того, что предыдущий ответ был потерян или совместимое изменение было сделано каким-то другим пользовательский агент).

Так что в случае условного УДАЛЕНИЯ нам явно разрешено отправить ответ 2xx, если ресурс уже удален.

... и я не нашел встречного аргумента в спецификации, чтобы предположить, что такое же поведение не должно использоваться для безусловного удаления. Он по-прежнему идемпотентен, текущее состояние ресурса отражает предполагаемое конечное состояние, кеши будут поступать правильно.

Так что отправка обратно 200 Yup we deleted the movie или 204 No Content оба смотрят на меня как на штрафа вариантов. (Примечание: 204 не означает, что у ресурса нет содержимого; это означает, что HTTP-ответ имеет тело сообщения длиной 0 байт).

Имеет ли это значение, вероятно, зависит от того, как интерпретаторы кэширования интерпретируют RFC 7231 4.3.5 - должны ли кэши аннулировать свои сохраненные представления при получении кода состояния ошибки?

Но так как мы можем быть уверены, что в кеше, совместимом с RFC 7234, все будет работать правильно, учитывая коды состояния без ошибок, я бы предпочел использовать их для этого случая.

Answer 3

Я думаю, что 404 определенно правильный подход. Клиент пытается что-то сделать с конкретным ресурсом. В этом случае УДАЛИТЕ это. Когда ресурс не может быть найден, и, следовательно, удаление не может быть выполнено, единственный четкий ответ мне кажется 404.

Ведь 404 - это ошибка клиента, которая указывает, что ресурс, на который ссылается клиент, тоже не может быть найден, но в противном случае сам запрос является действительным.

204 означает, что сервер успешно обработал запрос, но не вернул содержимое. Однако ресурс не был успешно удален, потому что он никогда не был найден. Так что 204 не применимо.