2013-04-21 2 views
2

У меня есть вызов REST, который принимает объект JSON, скажем, человека. После создания этого объекта (проверенного и сохраненного в базе данных) мне нужно вернуть вновь созданный объект JSON.REST - возврат созданного объекта с помощью Spring MVC

Я считаю, что стандартная практика заключается в возврате 201 Accepted вместо немедленного возврата объекта. Но мое приложение сразу нуждается в вновь созданном объекте.

У меня есть методы контроллера, он принимает вызов POST, вызывает служебный вызов, который, в свою очередь, вызывает DAO, который использует Hibernate для создания объекта. После его сохранения в базе данных я вызываю другой метод контроллера, который принимает идентификатор человека и возвращает объект.

Мой вопрос, это лучший подход? Это вызов другого метода контроллера для получения вновь созданного объекта. Или сам вызов POST должен вернуть объект.

Главный вопрос: Вызов другого метода принимает поездку туда и обратно, и я думаю, что это перебор. (Сервис-> DAO-> Hibernate-> Database). Вместо этого я думаю, что я должен получить объект из базы данных сразу после его сохранения в том же вызове (из метода, который обрабатывал POST)

Какой здесь стандарт архитектуры?

+0

201 «Создано». 202 «Принято». –

ответ

11

Попробуйте использовать ResponseEntity, который возвращает статус HTTP вместе с нужным вам объектом.

Пример кода (это был мой код, где я возвращал объект клиента, изменить его в соответствии с вашими потребностями):

// imports (for your reference) 
import org.springframework.http.HttpStatus; 
import org.springframework.http.ResponseEntity; 

// spring controller method 
@RequestMapping(value = "getcust/{custid}", method = RequestMethod.GET, produces={"application/json"}) 
public ResponseEntity<Customer> getToken(@PathVariable("custid") final String custid, HttpServletRequest request) { 

    customer = service.getCustById(custid); 

    return new ResponseEntity<Customer>(customer, HttpStatus.OK); 
} 

documentation Прочитайте это, чтобы узнать больше. Там был предоставлен некоторый пример кода.

+2

Это для GET. Но что, если вы хотите вернуть объект Customer с POST. Это создать, а затем немедленно вернуть это. Вы вызываете вышеуказанный метод GET для возврата или вы получаете объект JSON сразу после его сохранения в том же методе POST-вызова? –

+0

Это пример кода, для вашего понимания. Я просто хотел объяснить вам, как вы можете вернуть объект вместе с http-статусом. Если вы используете спящий режим, вы можете получить постоянный объект, который вы можете немедленно вернуть вместе с статусом Http (201). –

5

Из HTTP specification for POST:

Если ресурс был создан на исходном сервере, ответу СЛЕДУЕТ 201 (создания) и содержать объект, который описывает состояние запроса и ссылается на новый ресурс , и заголовок Location (см. раздел 14.30).

Что вы будете возвращаться в тело ответа будет зависеть от того, насколько строго вы интерпретируете an entity which describes the status of the request and refers to the new resource - и много реализаций просто возвращает представление самого вновь созданного объекта. Самое главное - установить заголовок Location в ответе как URI вновь созданного ресурса, чтобы клиенты могли сразу его извлечь, если они этого захотят.

+0

Вопрос заключается в подходе к возврату созданного объекта. 1.) Вызов другого метода GET контроллера или 2.) Возврат из того же метода POST, который создал объект. –

+0

Вы прочитали мой ответ? Или вы спрашиваете, как конкретно вернуть объект из POST весной? – Perception

+0

Да, это отвечает на первую часть. «Что нужно вернуть». Но другая часть вопроса: «Каков стандартный/лучший способ вернуть сам объект в тело ответа». Не в заголовке местоположения.Я понимаю и соглашаюсь с тем, что я должен вернуть '201 Created', а затем местоположение/URI этого ресурса в заголовке. Но наше требование - вернуть реальный объект JSON в самом теле. Не могли бы вы сообщить мне об этом? –

0

Вы можете вернуть объект объекта сразу после его сохранения с помощью @ResponseBody после @ResponseStatus, но он не является стандартным, поэтому ваш клиент должен знать об этой настройке, иначе, если ваш клиент зависит от стандартных API, приклеивается к стандарту, возвращая пустоту.