Discussion :

[Vyrob]

Bonjour tout le monde,

Une question me turlupine depuis un moment maintenant, et elle est plus ou moins dans le titre : quelle est la plue-value réelle de la technologie servlet par rapport au standard JAX-RS ? En d'autres termes, qu'est-ce qu'on peut faire avec des servlets qu'on ne peut pas faire avec JAX-RS ?

D'avance merci pour vos réponses.

[Vyrob]

Up !

[OButterlin]

On n'est pas dans le même registre là, JAX-RS est un service web là où Servlet est lié au protocole http(s).
En d'autres termes, tes services JAX peuvent être appelés par des programmes en langage C/C++, Java, d'autres services, Servlet etc...
Tes servlets vont répondre uniquement à une requête http.
En contrepartie, ta servlet va pouvoir générer un résultat direct à une requête http alors que ton service web devra être utilisé par autre chose avant de générer un contenu visible par un navigateur (encore que, ça dépend de ce que renvoie le service...)

[tchize_]

qu'est-ce qu'on peut faire avec des servlets qu'on ne peut pas faire avec JAX-RS ?

On peut faire tout ce qui n'est pas service REST.

[Vyrob]

En contrepartie, ta servlet va pouvoir générer un résultat direct à une requête http alors que ton service web devra être utilisé par autre chose avant de générer un contenu visible par un navigateur (encore que, ça dépend de ce que renvoie le service...)

Je ne connais que très peu JAX-RS, donc je vais peut-être dire des bêtises mais de ce que j'ai lu à droite à gauche, on peut très bien faire du MVC en retournant un Viewable. On peut également injecter l'objet request en argument de la méthode grâce à l'annotation @Context, permettant ainsi, à l'instar de ce qui est faisable avec des servlets, de définir des attributs affichables dans la vue (une jsp). Partant de là, je ne vois pas ce qu'une servlet apporte de plus.

qu'est-ce qu'on peut faire avec des servlets qu'on ne peut pas faire avec JAX-RS ?

On peut faire tout ce qui n'est pas service REST.

Comme je l'ai montré au-dessus, on peut faire la même chose qu'avec une servlet concernant la gestion des requêtes (avec l'objet request on peut même accéder à la session, on sort donc des limite du REST qui impose d'être stateless par essence). Donc j'avoue qu'a priori je ne suis pas trop d'accord avec cette affirmation, mais je passe peut-être à côté de quelque chose. :-O

[tchize_]

JAX-RS est basée sur les servlet, donc oui tu peux avoir accès à la servlet sous jacente via certains mécanisme et faire ce qu'on fait avec une servlet pure, mais c'est overkill. C'est le plaisir d'utiliser jax rs pour manipuler le système sousjacent, autant utiliser le système sous jacent directement, c'est plus facile à manipuler. De la même manière que je peux me rendre à pieds à mon travail, je met quand même deux jours de moins en allant en voiture :/

[OButterlin]

Faire du web service juste pour faire ce que fait une servlet, je ne vois pas trop l'intérêt...
Faire du web service pour partager des données avec des clients de nature et langages différents, là, oui

La question est, quel type d'application veux-tu faire, la couche métier sera-t-elle partagée avec d'autres application, etc...
Si c'est pour faire une application web standard, autant faire simple.

[Vyrob]

JAX-RS est basée sur les servlet, donc oui tu peux avoir accès à la servlet sous jacente via certains mécanisme et faire ce qu'on fait avec une servlet pure, mais c'est overkill. C'est le plaisir d'utiliser jax rs pour manipuler le système sousjacent, autant utiliser le système sous jacent directement, c'est plus facile à manipuler. De la même manière que je peux me rendre à pieds à mon travail, je met quand même deux jours de moins en allant en voiture :/

Je comprends ce que tu veux dire, mais selon moi il reste quand même des atouts que n'ont pas les servlets pures et qui justifie de passer par l'intermédiaire de JAX-RS pour autre chose que par pure plaisir. A savoir :

• une gestion plus puissante des URLs (permettant ainsi d'avoir des paramètres qui se fondent dedans et d'avoir ainsi de jolies URLs genre /user/1/right/2 en lieu et place de /user/right/?uid=1&did=2 avec mapping automatique côté serveur et contraintes sur le type),
• une organisation plus claire des actions avec possibilité de définir un chemin par méthode.

[OButterlin]

une gestion plus puissante des URLs (permettant ainsi d'avoir des paramètres qui se fondent dedans et d'avoir ainsi de jolies URLs genre /user/1/right/2 en lieu et place de /user/right/?uid=1&did=2 avec mapping automatique côté serveur et contraintes sur le type)

On peut faire la même chose avec Apache

une organisation plus claire des actions avec possibilité de définir un chemin par méthode.

On peut faire la même chose avec Apache

Ce ne sont pas des arguments vraiment imparables pour dire que JAX-RS est mieux...

[Vyrob]

On peut faire la même chose avec Apache

Ce ne sont pas des arguments vraiment imparables pour dire que JAX-RS est mieux...

"Avec Apache", on sort donc du standard Java pur à ce moment-là.

Après ne soyons pas de mauvaise foi, j'imagine que dans la majorité des cas on aura un Apache couplé au serveur d'application, je ne dis pas, mais ça reste quand même moins lourd à gérer directement dans des classes Java à l'aide d'annotations que d'aller écrire des rewrite rules dans la conf Apache à chaque nouvelle action qu'on développe, non ?

[OButterlin]

Disons qu'Apache n'a rien à voir avec Java, c'est juste un serveur web.

Pour les url, la façon de passer les paramètres est un détail de fonctionnement, par contre l'architecture globale à base de web service ou de servlet est une toute autre histoire.

Si je dois faire une application web uniquement, j'utiliserai les servlets (enfin, de loin, les frameworks modernes nous éloignent de la base)
Si je dois faire une couche métier utilisable par n'importe quel type de client, je préférerai les web services
Si mes clients sont des classes java (locale ou distante), je préfèrerai les EJB

Mais ça reste un avis, tu as le droit d'en avoir un autre

[Vyrob]

Disons qu'Apache n'a rien à voir avec Java, c'est juste un serveur web.

Yep je sais, je voulais juste souligner que la technologie servlet ne se suffisait pas à elle-même dans ce cas précis. ^^

Pour les url, la façon de passer les paramètres est un détail de fonctionnement, par contre l'architecture globale à base de web service ou de servlet est une toute autre histoire.

Pourrais-tu expliciter ce point (en bref, sans nécessairement rentrer dans les détails) ? En quoi l'architecture de l'application web change-t-elle aussi drastiquement entre une à base de web services et une à base de servlets ?

Si je dois faire une application web uniquement, j'utiliserai les servlets (enfin, de loin, les frameworks modernes nous éloignent de la base)
Si je dois faire une couche métier utilisable par n'importe quel type de client, je préférerai les web services
Si mes clients sont des classes java (locale ou distante), je préfèrerai les EJB

Mais ça reste un avis, tu as le droit d'en avoir un autre

Bah si j'ai posté ici c'est bien pour récolter des avis différents pardi !

[tchize_]

Je comprends ce que tu veux dire, mais selon moi il reste quand même des atouts que n'ont pas les servlets pures et qui justifie de passer par l'intermédiaire de JAX-RS pour autre chose que par pure plaisir. A savoir :

• une gestion plus puissante des URLs (permettant ainsi d'avoir des paramètres qui se fondent dedans et d'avoir ainsi de jolies URLs genre /user/1/right/2 en lieu et place de /user/right/?uid=1&did=2 avec mapping automatique côté serveur et contraintes sur le type),
• une organisation plus claire des actions avec possibilité de définir un chemin par méthode.

Oui, c'est une possibilité et si elle te plait, utilise la. Mais toutes les applications développées en java ne veulent pas nécessairement avoir les paramètres dans l'URL ou ne sont pas capable de déterminer l'action à exécuter uniquement à partir des paramètres. Si tu veux faire du rest, cette api est bien faite pour. Mais si tu veux faire autre chose que du REST, ça ne passe pas.

JAX-RS est une spécialisation de Servlet, qui fait très bien son boulot et permet de cacher pas mal de plomberie à l'utilisateur. C'est bien tant que les pragmatismes imposés par cet outil te conviennent. Mais ça ne couvre pas tous le champs des besoins des développeurs.
Quand je fais du JSF, je n'utilise pas jax-rs, j'utilise JSF, qui est une autre spécialisation de servlet basée sur un autre pragmatisme. Il y a aussi spring mvc, les jsp, ....

[OButterlin]

Pourrais-tu expliciter ce point (en bref, sans nécessairement rentrer dans les détails) ? En quoi l'architecture de l'application web change-t-elle aussi drastiquement entre une à base de web services et une à base de servlets ?

Ça dépend un peu de qui appel, si on se cantonne à un appel depuis un navigateur, les différences ne sont pas flagrantes, mais ce n'est pas le seul usage des web services, ils servent plus généralement à de l'interopérabilité entre applications hétérogènes...

En se limitant au cas "navigateur", une architecture à base de web services traverse plus de couches qu'un traitement direct et est donc moins performante (ça reste certainement anecdotique comparé au temps de transport).

Pour l'interopérabilité, elle est limitée à des paramètres "sérialisables" xml...
Avec une architecture servlet/EJB, on pourrait (à priori, mais je n'ai pas testé encore) utiliser les lambdas, ce qui ouvre des possibilités nouvelles...
Bref, ça change les possibilités, ensuite, rien ne dit que l'application en a besoin...

Comme dit, je n'ai rien contre les services web, je pense juste qu'on devrait les limiter à l'interopérabilité en milieu hétérogène.
Pour le monde java, il y a mieux et plus simple