Различие ч / б @ResponseStatus и ResponseEntity.created (location) .build () в методе post контроллера покоя при весенней загрузке

Question

Для метода post в контроллере Rest я хочу вернуть 201 код состояния. я видел два подхода к этому. Первый -

@PostMapping("/offers")
     @ResponseStatus(HttpStatus.CREATED)
    public Offer createOffer(@Valid @RequestBody Offer offer) {
        return offerRepository.Save(offer);
    }

второй подход

@PostMapping("/offers")
    public ResponseEntity<Object> createOffer(@Valid @RequestBody Offer offer) {
        return offerService.createOffer(offer);
    }

ниже мой класс обслуживания @Override public ResponseEntity<Object> createOffer(Offer offer) { Offer uOffer=OfferRepository.save(offer); URI location = ServletUriComponentsBuilder.fromCurrentRequest().path("/{jobTitle}"). buildAndExpand(uOffer.getJobTitle()).toUri(); return ResponseEntity.created(location).build(); }

поэтому мой вопрос касается первого подхода: мы не используем какие-либо вещи, созданные ResponseEntity.Ceat, так как мы просто возвращаем @ResponseStatus(HttpStatus.CREATED) из контроллера. Но через секунду мы не используем @ResponseStatus(HttpStatus.CREATED), и мы обрабатываем этот код состояния 201 с помощью URI и отзывчивость.

В чем разница между двумя подходами? Кажется, они одинаковы, так как они возвращают один и тот же код ответа 201. Какой из них предпочтительнее?

Answer 1

В общем, нет никакой разницы, когда дело доходит до кодов состояния. В конце концов, вы все равно получите ответ HTTP с кодом состояния 201. Однако при втором подходе вы также возвращаете заголовок Location, который является предпочтительным способом. Из HTTP-руководства Mozilla:

Код ответа HTTP 201 Created Status Status означает, что запрос выполнен успешно и привел к созданию ресурса. Новый ресурс эффективно создается до того, как этот ответ отправляется обратно, и новый ресурс возвращается в теле сообщения, причем его местоположением является либо URL-адрес запроса, либо содержимое заголовка Location.

Answer 2

На мой взгляд, вы должны применять следующие правила.Если вы хотите вернуть ResponseEntity, используйте это, чтобы повлиять на статус.Таким образом, что-то вроде:

@PostMapping("/offers")
public ResponseEntity<Offer> createOffer(@Valid @RequestBody Offer offer) {
     Offer offer = offerService.createOffer(offer);
     URI location = ServletUriComponentsBuilder.fromCurrentRequest().path("/{jobTitle}").
                buildAndExpand(uOffer.getJobTitle()).toUri();
     return ResponseEntity.created(location)
                          .body(offer)
                          .build(); 
}

Не разрешайте вашей службе генерировать ResponseEntity, так как это класс представления для контроллеров и не должен быть в службе.

Второй вариант - использованиекласс, а не ответная сущность.Тогда пример будет выглядеть примерно так:

@PostMapping("/offers")
@ResponseStatus(HttpStatus.CREATED)
public Offer createOffer(@Valid @RequestBody Offer offer) {
     // Do not return response entity but the offer
     return offerService.createOffer(offer);
}

Answer 3

Первый подход является предпочтительным, так как он позволяет вам отделить сервисный слой от вашего веб-слоя (сервисный слой не должен знать о HttpEntity и всех подобных вещах, поэтому он может потенциально использоваться повторно без веб-слоя ).

Вы должны изменить свой метод обслуживания, чтобы он возвращал Object вместо ResponseEntity<Object>.