java - requestmapping - ¿Qué devolver si el método del controlador Spring MVC no devuelve el valor?

para que sirve spring mvc

Question

Estoy usando $.getJSON() jQuery para hacer llamadas asincrónicas a mi backend Spring MVC simple. La mayoría de los métodos de controlador Spring se ven así:

@RequestMapping(value = "/someURL", method = RequestMethod.POST)
public @ResponseBody SomePOJO getSomeData(@ModelAttribute Widget widget,
@RequestParam("type") String type) {
return someDAO.getSomeData(widget, type);
}

Tengo las cosas configuradas para que cada controlador devuelva @ResponseBody como JSON, que es lo que el cliente espera.

Pero, ¿qué sucede cuando se supone que una solicitud no devuelve ningún contenido al lado del cliente? Puedo tener:

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
public @ResponseBody void updateDataThatDoesntRequireClientToBeNotified(...) {
...
}

Si no, ¿cuál es la sintaxis apropiada para usar aquí? ¡Gracias por adelantado!

Answer 1

Aquí está el código de ejemplo de lo que hice para un método asíncrono

@RequestMapping(value = "/import", method = RequestMethod.POST)
@ResponseStatus(value = HttpStatus.OK)
public void importDataFromFile(@RequestParam("file") MultipartFile file)
{
accountingSystemHandler.importData(file, assignChargeCodes);
}

No es necesario que devuelva nada de su método, todo lo que necesita para usar esta anotación, para que su método sea correcto en todos los casos.

@ResponseStatus(value = HttpStatus.OK)

Answer 2

No hay nada de malo en devolver un void @ResponseBody y debería hacerlo para las solicitudes POST .

Use los códigos de estado HTTP para definir los errores dentro de las rutinas del manejador de excepciones, ya que otros mencionan el estado de éxito. Un método normal como el que tiene devolverá un código de respuesta de 200 que es lo que quiere, cualquier controlador de excepción puede devolver un objeto de error y un código diferente (es decir, 500 ).

Answer 3

Pero a medida que su sistema crece en tamaño y funcionalidad ... creo que volver siempre a JSON no es una mala idea. Es más una cuestión de arquitectura / "diseño a gran escala".

Puedes pensar en retoting siempre un JSON con dos campos conocidos: código y datos. Donde el código es un código numérico que especifica el éxito de la operación a realizar y los datos son datos adicionales relacionados con la operación / servicio solicitado.

Vamos, cuando utilizamos un proveedor de servicios de back-end, se puede verificar cualquier servicio para ver si funcionó bien.

Así que me adhiero, para no dejar que la primavera lo administre, exponiendo las operaciones de retorno híbridas (algunos datos devueltos, nada, nada ...) ... instalados, asegúrese de que su servidor exponga una interfaz más homogénea. Es más simple al final del día.

Answer 4

Puede devolver el objeto "ResponseEntity". El uso del objeto "ResponseEntity" es muy conveniente tanto en el momento de construir el objeto de respuesta (que contiene el cuerpo de respuesta y el código de estado HTTP) como al momento de obtener información del objeto de respuesta.

Métodos como getHeaders (), getBody (), getContentType (), getStatusCode () etc hacen que el trabajo de lectura del objeto ResponseEntity sea muy fácil.

Debe utilizar el objeto ResponseEntity con un código de estado http de 204 (Sin contenido), que es específicamente para especificar que la solicitud se ha procesado correctamente y que el cuerpo de la respuesta está intencionalmente en blanco. Usar los códigos de estado apropiados para transmitir la información correcta es muy importante, especialmente si está haciendo una API que va a utilizar varias aplicaciones cliente.

Answer 5

Sí, puedes usar @ResponseBody con el tipo de devolución void :

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
@ResponseBody
public void updateDataThatDoesntRequireClientToBeNotified(...) {
...
}

Answer 6

Simplemente puede devolver una ResponseEntity con el encabezado apropiado:

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
public ResponseEntity updateDataThatDoesntRequireClientToBeNotified(...){
....
return new ResponseEntity(HttpStatus.OK)
}

Answer 7

puede volverse vacío, luego debe marcar el método con @ResponseStatus (value = HttpStatus.OK) no necesita @ResponseBody

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
@ResponseStatus(value = HttpStatus.OK)
public void updateDataThatDoesntRequireClientToBeNotified(...) {
...
}

Solo los métodos get devuelven una implicidad de código de estado de 200, todos los demás tienen una de estas tres cosas:

• Devuelve nulo y marca el método con @ResponseStatus(value = HttpStatus.OK)
• Devuelve un objeto y márcalo con @ResponseBody
• Devuelve una instancia de HttpEntity