Et pour finir cette série d'article, nous allons nous intéresser à la génération de JSon avec Jersey et bien sûr à sa testabilité.
Le xml, c'est bien gentil, mais dans des échanges REST ça peut être un peu lourd, surtout si le consommateur est un appareil mobile. La génération JSon avec Jersey peut s'appuyer sur JAX-B. Et oui, c'est justement pour cela que l'on s'en est occupé dans le précédant article. Le mapping, lui, ne change pas.
La resource ne nécessite qu'un petit changement :
@GET
@Path("{name}")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public Hello reply(@PathParam("name") String name){
return helloService.saysHelloToSomeone(name);
}
Comme on est sympa, on permet de renvoyer soit du Json, soit du Xml, c'est le consommateur qui décide. Par défaut, c'est le 1er format qui est choisit, soit le JSon.
La génération JSon va nécessiter un peu de configuration, principalement à cause du type de JSon généré. C'est le ContextResolver qui va s'occuper de ça :
@Provider
@Singleton
public class JAXBContextResolver implements ContextResolver<JAXBContext> {
/** Package that contains object that can be mapped */
private static final String JAXB_OBJECT_PACKAGE = Hello.class.getPackage().getName();
private final JAXBContext context;
public JAXBContextResolver() throws Exception {
this.context = new JSONJAXBContext(JSONConfiguration.natural().build(),
JAXB_OBJECT_PACKAGE);
}
@Override
public JAXBContext getContext(Class<?> objectType) {
if(objectType.getPackage().getName().equals(JAXB_OBJECT_PACKAGE)){
return context;
}
return null;
}
}
Ici le type de JSon souhaité est le natural. Cet objet doit être passés dans le même package que les resources, il profitera ainsi lui aussi de la découverte automatique au démarrage de Guice. Ce resolver n'est pas obligatoire, sans lui, le JSon généré est par défaut en mode mapped.
La configuration des tests, va devoir évoluer un peu pour prendre en compte notre génération en ode natural. La méthode configure() devient :
@Override
protected AppDescriptor configure() {
ClientConfig clientConfig = new DefaultClientConfig();
clientConfig.getClasses().add(JAXBContextResolver.class);
injector = Guice.createInjector(new ServletModule() {
@Override
protected void configureServlets() {
bind(getTestingResourceClass());
bind(JAXBContextResolver.class);
serve("/*").with(GuiceContainer.class);
}
});
return new WebAppDescriptor.Builder()
.contextListenerClass(GuiceTestConfig.class)
.filterClass(GuiceFilter.class)
.clientConfig(clientConfig)
.servletPath("/")
.build();
}
Ainsi du coté serveur comme du coté client, les échanges seront dans le même format. Nos tests deviendront :
@Test
public void shoulReplyHelloInXml(){
doShoulReplyHello(MediaType.APPLICATION_XML_TYPE);
}
@Test
public void shoulReplyHelloInJson(){
doShoulReplyHello(MediaType.APPLICATION_JSON_TYPE);
}
private void doShoulReplyHello(MediaType type){
String message = "Hello";
String name ="Nicolas";
Hello hello = new Hello(message, name);
when(helloServiceMock.saysHelloToSomeone("Nicolas")).thenReturn(hello);
ClientResponse response = resource().path("hello").path(name)
.accept(type).get(ClientResponse.class);
verify(helloServiceMock).saysHelloToSomeone(name);
assertThat(response.getClientResponseStatus()).isEqualTo(Status.OK);
assertThat(response.getType()).isEqualTo(type);
Hello entity = response.getEntity(Hello.class);
assertThat(entity).isNotNull().isEqualTo(hello);
}
Une des différenciation entre les types de JSon générés se fait sur la façon dont sont écrites les listes. En mode natural, nous avons par exemple : objet1, objet2, ... avec des objet {"attributA":"valeurA", ....}
Imaginons que nous avons une autre ressource qui par grande politesse retourne 2 Hellos :
@Path("doublehello")
@Singleton
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public class DoubleHelloResource {
@Inject
private HelloService helloService;
@GET
@Path("/{name}")
public List<Hello> reply(@PathParam("name") String name){
List<Hello> hellos = new ArrayList<Hello>();
hellos.add(helloService.saysHelloToSomeone(name));
hellos.add(helloService.saysHelloToSomeone(name));
return hellos;
}
}
Pour vérifier sa bonne génération, nous aurions le test suivant :
@Test
public void shoudHaveTwoHello(){
String message = "Hello";
String name ="Nicolas";
when(helloServiceMock.saysHelloToSomeone("Nicolas"))
.thenReturn(new Hello(message, name));
ClientResponse response = resource().path("doublehello").path(name)
.get(ClientResponse.class);
assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
assertThat(response.getType()).isEqualTo(MediaType.APPLICATION_JSON_TYPE);
List<hello> hellos = response.getEntity(new GenericType<List<Hello>>(){});
assertThat(hellos).isNotNull().hasSize(2);
}
@Test
public void shoudBeInNaturalJson(){
String message = "Hello";
String name ="Nicolas";
when(helloServiceMock.saysHelloToSomeone("Nicolas"))
.thenReturn(new Hello(message, name));
ClientResponse response = resource().path("doublehello").path(name)
.get(ClientResponse.class);
assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
assertThat(response.getType()).isEqualTo(MediaType.APPLICATION_JSON_TYPE);
String hellos = response.getEntity(String.class);
assertThat(hellos).isEqualTo(naturalHelloJSon(message, name));
}
public String naturalHelloJSon(String message, String name){
StringBuilder sb = new StringBuilder();
sb.append("[{\"message\":\"").append(message)
.append("\",\"name\":\"").append(name).append("\"},");
sb.append("{\"message\":\"").append(message)
.append("\",\"name\":\"").append(name).append("\"}]");
return sb.toString();
}
Même s'il est un format intéressant, le JSon souffre d'un problème lié au javascript : celui du cross-domain qui fait que l'on ne peut pas interroger un autre domain que celui de la page web. <a href="http://en.wikipedia.org/wiki/JSONP">JSonP</a> permet d'évincer cette contrainte.
Jersey permet aussi de générer ce type de réponse mais un peu moins facilement. Nous allons créer une nouvelle méthode pour ce type de réponse :
@GET
@Path("{name}.jsonp")
@Produces("application/x-javascript")
public JSONWithPadding replyWithJsonP(@PathParam("name") String name,
@QueryParam("callback") @DefaultValue(CALLBACK_DEFAULT_NAME) String callback){
Hello hello = helloService.saysHelloToSomeone(name);
return new JSONWithPadding(hello, callback);
}
Son test reste dans l'optique des précédents :
@Test
public void shoudBeJsonpWithCallbackNameParam(){
String message = "Hello";
String name ="Nicolas";
when(helloServiceMock.saysHelloToSomeone("Nicolas")).thenReturn(new Hello(message, name));
String callbackName = "monCallback";
ClientResponse response = resource().path("hello").path(name+".jsonp")
.queryParam("callback", callbackName)
.get(ClientResponse.class);
assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
assertThat(response.getType().toString()).isEqualTo("application/x-javascript");
assertThat(response.getEntity(String.class)).isNotNull().startsWith(callbackName);
}
Je n'ai pas malheureusement pas trouvé comment unmarshmaller ce message.
Et voilà, ce tour d'horizon est fini, amusez vous bien avec ces quelques technos. Comme à chaque fois, le code source est disponible
Dans le
cadre d'un projet sur lequel je suis intervenu, j'ai eu a refactorer le format
des URIs d'un middleware RESTful. Ce fut également l'occasion d'introduire
