Skip to main content
EspañolExampleGradleJakarta EEJava EETutorial

Valida tus Microservicios on MicroProfile y Bean Validation

By July 10, 2019July 11th, 2019No Comments

Es muy común que en nuestros microservicios estén llenos de múltiples validaciones con bloques de if’s en los cuales probamos si el valor no es nulo, si tiene una longitud adecuada, fechas correctas, etc. y luego debemos informarle al usuario que fue lo que salió mal… y el 50% de nuestro código se basa en esas validaciones.

Afortunadamente entre las API’s de JavaEE/JakartaEE encontramos Bean Validation, que permite reducir todo ese código de una forma declarativa usando anotaciones y podemos aprovecharlas junto a MicroProfile para escribir microservicios que no solo comuniquen al usuario que ocurrió un error, si no que además indique que fué lo que salió mal y como puede corregirlo.

Todo el código que veremos a continuación se puede encontrar en el siguiente repositorio:
https://github.com/Motojo/MicroProfile-BeanValidation

Integrando Bean Validation a nuestro proyecto

Para integrar Bean Validation a nuestro proyecto, basta con agregar la dependencia a las API’s completas de JavaEE/JakartaEE o únicamente al proyecto de Bean Validation.

 

  1. dependencies {
  2.    /*--- Full JavaEE dependency or just javax.validation dependency   ---*/
  3.    /* providedCompile group: 'javax', name: 'javaee-api', version: '8.0' */
  4.    providedCompile group: 'javax.validation', name: 'validation-api', version: '2.0.1.Final'
  5.    providedCompile group: 'org.eclipse.microprofile', name: 'microprofile', version: '2.1'
  6. }

Ejemplo utilizando Gradle

 

Una vez integrado podemos empezar a utilizar las anotaciones en nuestros POJO’s según las validaciones que necesitemos, por ejemplo:

  • @NotNull: Verifica que la propiedad no tenga valor null.
  • @AssertTrue: Verifica que la propiedad tenga valor true.
  • @Size: Verifica que la propiedad tenga un tamaño entre los valores min y max, aplica a Strings, Mapas, Colecciones y Arrays. 
  • @Min:  Verifica que la propiedad tenga un valor numérico igual o mayor al especificado
  • @Max:Verifica que la propiedad tenga un valor numérico igual o menor al especificado.
  • @Email: Verifica que la propiedad sea un Email válido.
  • @NotEmpty:Verifica que la propiedad no esté vacía, aplica a Strings, Colecciones, Mapas o Arrays.
  • @NotBlank:Verifica que el texto no sea null o espacios en blanco.
  • @Positive / @PositiveOrZero: Verifica que el valor numérico sea positivo incluyendo o no al cero.
  • @Negative / @NegativeOrZero: Verifica que el valor numérico sea positivo incluyendo o no al cero.
  • @Past / @PastOrPresent:  Verifica que la fecha esté en el pasado incluyendo o no el presente.
  • @Future / @FutureOrPresent:  Verifica que la fecha esté en el futuro incluyendo o no el presente.

Y pueden utilizarse de la siguiente manera:

  1. public class Book
  2. {
  3.    private Long id;
  4.  
  5.    @NotNull
  6.    @Size(min = 6)
  7.    private String name;
  8.  
  9.    @NotNull
  10.    private String author;
  11.  
  12.    @Min(6)
  13.    @Max(200)
  14.    @NotNull
  15.    private Integer pages;
  16. }

Ejemplo de POJO anotado con Bean Validation

 

Integrando Bean Validation con JAX-RS

Una vez que Bean Validation se encuentra integrado en nuestro proyecto y nuestros objetos a validar se encuentran anotados, es momento de indicarle a nuestros microservicios que deben de realizar o no las validaciones correspondientes, y esto se hace de la siguiente manera utilizando la anotación @Valid:

 

  1. @POST
  2. public Book createBook(@Valid Book book)
  3. {
  4.    //Do something like saving to DB and then return the book with a new ID
  5.    book.setId(20L);
  6.    return book;
  7. }

Ejemplo de WebService validado por medio de Bean Validation

 

Al invocar nuestro servicio se realizarán las validaciones indicadas en el objeto Book y nos devolverá un error si algún parámetro es incorrecto o procederá a ejecutar el código de nuestro WebService si todo está correcto.

 

Ejemplo de WebService ejecutado correctamente

 

Ejemplo de WebService con errores (nombre del libro no enviado)

 

Mejorando el manejo de errores

Como pudimos observar en la imagen anterior, al existir un error el código del WebService no fué ejecutado y en lugar se envió la respuesta standard de error de nuestro servidor, sin embargo esto no es muy útil y puede causar aún más errores si quien consume el servicio espera que las respuestas estén en formato JSON.

Para mejorar nuestras respuestas e indicarle al usuario que fué lo que salió mal podemos escribir un pequeño interceptor del tipo ExceptionMapper<ConstraintViolationException> que transformará nuestra respuesta a JSON y brindará información más util al usuario para corregir su error.

 

  1. @Provider
  2. public class ValidationExceptionMapper implements ExceptionMapper<ConstraintViolationException>
  3. {
  4.    private String getPropertyName(Path path)
  5.    {
  6.        //The path has the form of com.package.class.property
  7.        //Split the path by the dot (.) and take the last segment.
  8.        String[] split = path.toString().split("\\.");
  9.        return split[split.length - 1];
  10.    }
  11.  
  12.    @Override
  13.    public Response toResponse(ConstraintViolationException exception)
  14.    {
  15.        Map<String, String> errors = exception.getConstraintViolations().stream()
  16.        .collect(Collectors.toMap(v -> getPropertyName(v.getPropertyPath()), ConstraintViolation::getMessage));
  17.  
  18.        return Response.status(Response.Status.BAD_REQUEST)
  19.                .entity(errors).type(MediaType.APPLICATION_JSON)
  20.                .build();
  21.    }
  22. }

Interceptor para mejorar la respuesta estándar al ocurrir un error

 

Una vez escrito y registrado nuestro interceptor con la anotación @Provider al invocar nuestro servicio y si este tiene algún error en lugar de retornar la pantalla estándar de nuestro servidor nos retornará una respuesta similar a esta:

 

Ejemplo de WebService con errores utilizando el ExceptionMapper

 

Parametros en Query, Path y Header:

El uso de Bean Validation no se limita a objetos que se reciban como parte del cuerpo de la petición, también pueden ser aplicados a parámetros dentro de la URL como los Path y Query Params o validación de los headers, por ejemplo:

 

  1. @GET
  2. public Book getBook(@Valid @NotNull @QueryParam("id") Long id)
  3. {
  4.    //Just build a dummy book to return
  5.    Book book = new Book();
  6.    book.setId(id);
  7.    book.setAuthor("Jorge Cajas");
  8.    book.setPages(100);
  9.  
  10.    return book;
  11. }

Sin embargo al utilizar este servicio podemos notar que las respuestas en nuestro ExceptionMapper de errores ya no son tan útiles como esperábamos pues los nombres de los parámetros no son reconocidos automáticamente:

 

El error en el parámetro id no es reportado correctamente

 

Para corregir esto debemos de configurar a Bean Validation de tal forma que sepa de qué manera resolver los nombres de los parámetros de nuestros métodos JAX-RS.

El archivo validation.xml se utiliza para configurar varios aspectos de Bean Validation y debe colocarse en la carpeta de resources/META-INF. En este archivo colocaremos la propiedad <parameter-name-provider> con referencia a nuestra clase que se encargará de resolver los nombres de los parámetros de nuestros servicios JAX-RS.

 

  1. <validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  2.                    xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd" version="1.1">
  3.  
  4.    <parameter-name-provider>com.demo.validations.CustomParameterNameProvider</parameter-name-provider>
  5.  
  6. </validation-config>

resources/META-INF/validation.xml

 

La clase CustomParameterNameProvider inspeccionará nuestros servicios JAX-RS, obtendrá las anotaciones de los parámetros de Query, Path o Header y completará la información necesaria para que Bean Validation sepa cómo completar los nombres en nuestro ExceptionMapper que escribimos anteriormente.

 

  1. public class CustomParameterNameProvider implements ParameterNameProvider
  2. {
  3.    @Override
  4.    public List<String> getParameterNames(Constructor<?> constructor){
  5.        return lookupParameterNames(constructor.getParameterAnnotations());
  6.    }
  7.  
  8.    @Override
  9.    public List<String> getParameterNames(Method method) {
  10.        return lookupParameterNames(method.getParameterAnnotations());
  11.    }
  12.  
  13.    private List<String> lookupParameterNames(Annotation[][] annotations) {
  14.        final List<String> names = new ArrayList<>();
  15.        if (annotations != null) {
  16.            for (Annotation[] annotation : annotations) {
  17.                String annotationValue = null;
  18.                for (Annotation ann : annotation) {
  19.                    annotationValue = getAnnotationValue(ann);
  20.                    if (annotationValue != null) {
  21.                        break;
  22.                    }
  23.                }
  24.                // if no matching annotation, must be the request body
  25.                if (annotationValue == null) {
  26.                    annotationValue = "requestBody";
  27.                }
  28.                names.add(annotationValue);
  29.            }
  30.        }
  31.        return names;
  32.    }
  33.  
  34.    private static String getAnnotationValue(Annotation annotation) {
  35.        if (annotation instanceof HeaderParam) {  return ((HeaderParam) annotation).value(); }
  36.        else if (annotation instanceof PathParam) { return ((PathParam) annotation).value(); }
  37.        else if (annotation instanceof QueryParam) { return ((QueryParam) annotation).value(); }
  38.        return null;
  39.    }
  40. }

CustomParameterNameProvider.java

 

Una vez configurado, podemos volver a invocar nuestro servicio y la respuesta deberá ser similar a esta:

 

El query param id es reportado con error con el nombre correcto.

 

Next Post

You May Also Like

EventJakarta EEJavaMicroProfile CommunityVideo Sessions

MicroProfile Booth Experience at DevNexus 2024

Emerson Castañeda
Emerson CastañedaSeptember 17, 2024
DocumentationExampleJakarta EE 10MicroProfile 6.1MicroProfile CommunityMicroProfile ReactiveOpen LibertyWebSphere Liberty

Learn to write reactive microservices with MicroProfile Reactive Messaging 3.0

Laura Cowen
Laura CowenJune 3, 2024
DocumentationTutorial

Announcement: New Github Repository for MicroProfile Tutorial Content

Tarun Telang
Tarun TelangFebruary 28, 2024
Jorge Cajas

Author Jorge Cajas

More posts by Jorge Cajas

Leave a Reply

Close Menu