Mvgrebenuk Jul 7 2022 at 17:04

Изучаем ResponseEntity<?> и избавляемся от него в контроллерах Spring

5 min

58K

Java*

From sandbox

Comments 11

rogue06 Jul 7 2022 at 17:10

А как на счет кейса, когда мне нужно использовать ResponseEntity<> не только в случае ошибки. Например: при успешном создании объекта нам необходимо вернуть не 200 OK, а 201 CREATED. Что тогда? Придется его явно прописывать опять?

lampa Jul 7 2022 at 17:22

Предполагается, что для создания/изменения/удаления и просмотра вы используете разные эндпоинты

@ResponseStatus(HttpStatus.CREATED)

balakshinphil Jul 8 2022 at 09:52

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

lampa Jul 8 2022 at 11:38

"Гора" исключений на самом деле не гора, а структура для ответа ошибок. Ответы в одном месте, ошибки в другом. ResponseEntity - это конечный объект, кастомный exception - это то, что содержит объект запроса (например) и далее обрабатывается по своей логике. Постоянно наблюдаю в концепции ResponseEntity разные форматы ошибок (как одна из болей) для одной одинаковой ситуации в разных эндпоинтах. Ну и ломание дженериков вообще попахивает не очень))) В целом исчерпывающая статья https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc

ak0oval Jul 7 2022 at 17:29

В ControllerAdvice тоже можно избавиться от ResponseEntity (если хочется, конечно), применив аннотации ResponseBody и ResponseStatus. Пример:

    @ResponseStatus(HttpStatus.NOT_FOUND)
    @ExceptionHandler(ResourceNotFoundException.class)
    @ResponseBody
    public AppError handle(ResourceNotFoundException ex) {
      ...
    }

upagge Jul 7 2022 at 17:36

Все конечно замечательно, но зачем?

aleksandy Jul 8 2022 at 06:01

Потому что зачем просто, если можно сложно.

Lewigh Jul 8 2022 at 09:51

Рубрика "вредные советы". Сами создали проблему, сами героически пытаетесь ее решить непонятным образом.

Что здесь происходит? Вместо строгого типа Product, мы ставим ResponseEntity<?>, где под ? понимается любой Java объект.

Почему Вы сами не поставили параметр типа ответа а вместо него "?" и жалуетесь что не понятен тип?

    public Product findById(Long id) {
        return productsRepository.findById(id).orElseThrow(
                () -> new ResourceNotFoundException("Product with id " + id + " not found"));
    }

Вы когда логику вынесли в сервисы и радостно выбрасываете исключение, конечно же не подумали что если ресурс не найден то это не ошибка. Это вполне ожидаемое поведение. По нормальному нужно возвращать из метода Optional<Product> , и уже пользователь этого метода должен решать что делать если ресурса нет. А он может не просто бросить исключение а например:
- использовать значение по умолчанию
- попробовать выполнить альтернативный сценарий
В вашем сценарии все прибито гвоздями.

{
    "statusCode": 404,
    "message": "Product with id 299 nor found"
}

Т.е. фронт отправил запрос для получения Product по id=299 и когда ему приходит 404, он ну никак не сможет догадается о том что когда пошел за ресурсом Product по id=299 и получил статус код 404 - что ресурс не найден, обязательно нужно сообщение: "Product with id 299 nor found"?