Il y a déjà un long moment, j’avais posté une série d’article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow. Dans la continuité de cette course au plus léger, je me suis dit que cela pouvait être intéressant de faire une petite étude un peu plus exhaustive des solutions légères qui existaient. L’objectif étant extraire une sorte de bench un peu naïf et un peu out of the box.
Il y a quelques temps, j’avais fait une série d’articles sur resteasy-netty et resteasy-netty4. Cette article repart du même besoin, à savoir disposer d’une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty. Au niveau des besoins, ils seront identiques ie. : utiliser JAX-RS, intégrer Swagger, intégrer Jolokia, générer un livrable autoporteur. RestEasy-Netty, même s’il existe de nombreux points d’entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d’un mécanisme un peu limité concernant la partie sécurité.
Pour faire suite à mes articles resteasy-netty et resteasy-netty4, nous allons voir, dans cet article, comment il est possible de créer un service activator avec Spring Integration qui exposera via resteasy-netty4 un service REST. Ce service REST esposera simplement une opération en POST qui, via Spring Integration, écrira dans un fichier et qui, pour le fun, écrira également sur la console. Pour ce faire, rien de plus simple, un Service Activator de type gateway a été utilisé.
Pour faire suite à mon article précédent qui montrait comment il était possible de construire une stack légère basée sur Resteasy-Netty3, Jackson, Jolokia et Swagger, cet article montrera comment il est possible de faire la même chose avec Resteasy-Netty4 et Jackson 2. Même si les changements ne sont pas énormes, il y a quand même quelques variantes, et, histoire d’être exhaustif, cela permet de faire le tour complet… ;-)
L’informatique évolue constamment et c’est également le cas des architectures qui ont tendance à s’orienter de plus en plus vers l’utilisation de services REST. Ces services REST doivent, en outre, être de plus en plus véloces afin de pouvoir répondre à une charge de plus en plus forte (que ce soit d’un point de vue temps de réponse mais également d’un point de vue charge suportée). C’est dans ce contexte que des solutions comme Restlet ou RestX (pour n’en citer que quelques-unes) ont vu le jour.
