Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...


Tabla de contenidos
maxLevel4

...

Buenas Prácticas

Las principales indicaciones a la hora de construir una respuesta en un servicio REST (tanto para éxito como para error) son:

    • Usar la clase ResponseEntity<T> ( org.springframework.http.ResponseEntity) para envolver la respuesta.

    • Usar los códigos de estado de HTTP para indicar el resultado de la petición.

Este es el subconjunto de códigos de estado aconsejado para cada situación:

    • 200 - Sólo utilizar en caso de RESPUESTA CORRECTA en peticiones GET. No debe utilizarse cuando ocurre un error

    • 201 - Sólo utilizar en caso de RESPUESTA CORRECTA en peticiones POST y PUT.
    • 204 - Para respuestas a peticiones PUT, PATCH y DELETE correctas que no devuelven ningún body. (Ver documentación Spring)
    • 400 - Mensaje mal formado, petición o url incorrecta.

    • 401 - Fallo de autenticación.

    • 403 - Acceso no permitido a un recurso.

    • 404 - Recurso no encontrado.

    • 405 - Método HTTP (GET, POST, PUT…) no permitido.

    • 406 - MediaType solicitado no soportado (Accept en la petición y Produces del servicio no concuerdan).

    • 415 - ContentType enviado no soportado (ContentType en la petición y Consumes del servicio no concuerdan).

    • 500 - Error general en el servidor.

    • 503 - Servidor no disponible temporalmente.

La clase ResponseEntity proporciona varios métodos estáticos y builders para construir la respuesta en nuestros endpoints en base a estos códigos de forma muy rápida.

Es aconsejable usar estos códigos de estado HTTP mediante el enumerado org.springframework.http.HttpStatus.

Bloque de código
languagejava
themeEclipse
titleEjemplo ResponseEntity
collapsetrue
ResponseEntity
		.status(HttpStatus.NOT_FOUND)
		.body( ProblemDetailDto.builder()
		.status( status )
		.fecha(LocalDateTime.now())
		.build());

...

Spring Boot ofrece varios mecanismos para manejar excepciones y controlar las respuestas de error. Aunque todos son válidos, el enfoque recomendado es centralizar la gestión de errores mediante @ControllerAdvice. A partir de este mecanismo principal, el resto se entienden como herramientas complementarias.

  • ControllerAdvice

@ControllerAdvice permite interceptar y manejar excepciones de forma global, sin necesidad de duplicar lógica en cada controlador.

...