JAX-RS Frameworks [fermé]
https://stackoverflow.com/questions/80799
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je travaille sur l'implémentation de référence JAX-RS (Jersey). Je connais au moins deux autres frameworks (Restlet & Apache CXF).
Ma question est la suivante: quelqu'un a-t-il fait une comparaison entre ces cadres et, dans l'affirmative, quel cadre recommanderiez-vous et pourquoi?
La solution
FWIW utilise Jersey comme une panoplie de fonctionnalités (par exemple, WADL, vues implicites, support XML / JSON / Atom), appuyée par une communauté de développeurs importante et dynamique et dotée d'un excellent intégration printanière .
Si vous utilisez JBoss / SEAM, vous constaterez peut-être que RESTeasy s'intègre un peu mieux, mais si vous utilisez Spring for Dependency Injection, alors Jersey semble la mise en œuvre la plus simple, la plus populaire, la plus active et la plus fonctionnelle.
Autres conseils
Restlet contient une liste complète d'extensions pour Spring, WADL, XML, JSON et bien d'autres, notamment une extension pour l'API JAX-RS.
C’est également le seul cadre disponible en six éditions cohérentes :
- Java SE
- Java EE
- Boîte à outils Google Web
- Google AppEngine
- Android
- environnements OSGi
Ses principaux avantages sont les suivants:
- API client et serveur totalement symétriques lorsque JAX-RS a été conçu pour le traitement côté serveur Connecteurs
- pour des protocoles autres que HTTP (mappage sur la sémantique HTTP) lorsque JAX-RS est HTTP uniquement
- beaucoup plus de fonctionnalités incluant le contrôle complet du routage URI via l'API Restlet (mais peut être intégré à Servlet si nécessaire)
- disposition complète pour le support NIO
L'API JAX-RS peut constituer un bon choix si vous êtes limité aux API approuvées par JCP (n'utilisez pas Spring ni aucune extension des projets JAX-RS tels que Jersey et RESTeasy!). Sinon, Restlet est la solution la plus utilisée. cadre mature (initialement publié en 2005) et vous apportera, dans sa version 2.0, tous les avantages des annotations, combinés à un cadre puissant et évolutif orienté classe.
Pour une liste des fonctionnalités plus longue, consultez cette page .
Cordialement, Jérôme Louvel
Restlet ~ Fondateur et développeur principal ~ http://www.restlet.org
Mon équipe et moi-même utilisons beaucoup Restlet, mais pas ses fonctionnalités JAX-RS. Je peux vous dire que j'ai été très impressionné par les développeurs et la communauté Restlet; ils sont très actifs, engagés, réactifs et attachés à un cadre stable, efficace, fiable et performant. Je suis désolé, je ne peux pas répondre directement à votre principal intérêt, mais je pensais que mon expérience avec Restlet pourrait être précieuse.
Mon collègue explique pourquoi nous utilisons RESTeasy pour notre projet actuel dans Services Web RESTful dans Java EE avec RESTeasy (JAX-RS) :
Son implémentation de référence, Jersey, n’a pas été choisie parce que nous avons eu du mal à l’intégrer correctement à EJB3 et à Seam 2.0.
Nous utilisons l’implémentation RESTeasy de JAX-RS, car nous n’avons eu aucun problème à l’intégrer à nos EJB et à Seam. Il dispose également d’une documentation suffisante.
Il existe une autre implémentation d’Apache, mais je ne l’ai pas essayée car elle utilise une version plus ancienne de JAX-RS.
Enfin, il existe un autre cadre pour les services Web RESTful pour Java appelé Restlet, mais nous ne l’avons pas favorisé car, au moment de la rédaction de cet article, il utilise une architecture personnalisée, même si le support JAX-RS approprié est en cours.
Il semble qu'il existe 4 implémentations JAX-RS décentes, donc vous êtes probablement d'accord avec l'une d'elles. Pour ce que ça vaut, j'ai trouvé Jersey (1.0.2) vraiment sympa jusqu'à présent. Mes besoins sont assez modestes, un service simple, prendre en charge la plomberie, etc. Et ce maillot fait très bien.
Vous avez découvert qu'Apache Wink est très facile à utiliser, supporte JAX-RS et offre de nombreuses fonctionnalités au-delà de la norme.
Je n’utiliserais aucun cadre. Juste celui fourni avec votre serveur d'applications. Si vous utilisez des éléments spécifiques à un cadre, vous perdez la portabilité et vous ne pourrez plus vous en passer si le fournisseur du serveur d'applications inclut une version différente de votre cadre favori. Je vais m'en tenir à jax-ws.
