Servicios REST con Jersey.
0. Índice de contenidos.
- 1. Introducción
- 2. Entorno
- 3. Implementación del servicio
- 4. Configuración
- 5. Validación del cuerpo del mensaje
- 6. Gestión de excepciones
- 7. Conclusión
1. Introducción.
En este tutorial vamos a explorar las posibilidades que nos ofrece Jersey para validar los mensajes XML entrantes contra el esquema que tengamos definido.
También trataremos la gestión de excepciones que nos ofrece desacopladas de los servicios.
Aquí está la guía de usuario de la versión 1.11.
Para iniciaros con Jersey y sus anotaciones teneis un tutorial muy bueno de Germán.
Jersey: la implemetación de RESTFull de Sun
2. Entorno.
El tutorial está escrito usando el siguiente entorno:
- Hardware: MacBook Pro 15′ (2.8 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM).
- Sistema Operativo: Mac OS X Snow Leopard 10.6.3.
- NVIDIA GeForce 9600M GT 512Mb.
- Toshiba 500 Gb. 5400r.p.m.
3. Implementación del servicio.
Para este tutorial vamos a utilizar la versión 1.11 de Jersey.
Comenzamos añadiendo la dependencia en el pom.xml
|
1 2 3 4 5 |
<dependency> <groupid>com.sun.jersey</groupid> <artifactid>jersey-server</artifactid> <version>1.11</version> </dependency> |
No vamos a centrarnos en la propia funcionalidad a implementar en el servicio, sino simplemente en su diseño.
En la clase RestService definimos el servicio REST que queremos publicar.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
package com.adictosaltrabajo.rest; ... @Path("/rest/track/") public class RestService { @POST @Path("/add") @Consumes(MediaType.APPLICATION_XML) @Produces(MediaType.TEXT_PLAIN) public String postTrack(Track track, @Context ServletContext servletContext) { // ... return "200"; } } |
4. Configuración.
En el server.xml tenemos que añadir la configuración del servlet de Jersey.
También se configura el paquete donde se encuentran las clases anotadas.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
<display-name>Track Example</display-name> <servlet> <servlet-name>JerseyTest</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <init-param> <param-name>com.sun.jersey.config.property.resourceConfigClass</param-name> <param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value> </init-param> <init-param> <param-name>com.sun.jersey.config.property.packages</param-name> <param-value>com.adictosaltrabajo.rest</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>JerseyTest</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> |
5. Validación del cuerpo del mensaje
Creamos la clase TrackBodyReader que es la encargada de contruir el objeto de la petición, esto lo hace Jersey por si mismo pero implementando
esta interfaz asumimos el control de la construcción del objeto, permitiéndonos validar contra el esquema el mensaje de la petición.
De esta manera desacoplamos la validación de los mensajes de la propia lógica del servicio.
Podríamos realizar cualquier tipo de validación, en este caso simplemente comprobamos que el XML este bien formado y cumpla el esquema.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
package com.adictosaltrabajo.rest; ... @Provider @Consumes("application/xml") public class TrackBodyReader implements MessageBodyReader<Track> { private JAXBTrackBuilder builder = new JAXBTrackBuilder(); @Override public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType) { return type.isAssignableFrom(Track.class); } @Override public Track readFrom(Class<Track> type, Type genericType, Annotation[] annotations, MediaType mediaType, MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException { try { return builder.unmarshal(entityStream); } catch (Exception ex) { throw new WebApplicationException(ex); } } } |
6. Gestión de excepciones
Jersey nos proporciona una interfaz muy sencilla que nos permite capturar las excepciones que le definamos y devolver un mensaje
encapsulándolas de forma que podamos construir una respuesta con la propia traza o lo que creamos oportuno.
En este ejemplo se devuelven en texto plano, pero sería fáctible incluirlas en una respuesta XML ó JSON.
En este caso capturamos únicamente las excepciones de tipo «WebApplicationException» manteniendo aislado el propio servicio
de la gestión de las mismas.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
package com.adictosaltrabajo.rest; ... @Provider public class JAXBExceptionMapper implements ExceptionMapper<WebApplicationException> { @Override public Response toResponse(WebApplicationException exception) { return Response.status(Status.BAD_REQUEST). entity(exception.getMessage()). type(MediaType.TEXT_PLAIN). build(); } } |
7. Conclusión.
Como hemos visto, la propia implementación del servicio está desacoplada de la validación de los mensajes entrantes y de la gestión de excepciones,
esto nos permite tener clases con muy pocas líneas de código con una funcionalidad muy concreta y acotada.
Espero que os haya sido de utilidad.
Cualquier aclaración, duda o sugerencia podéis incluirla en la zona de comentarios.
Un saludo.
Alvaro Cuesta.
