Par exemple, Play-Framework prend en charge des services reposants tels que celui-ci: reposant! cadre
Comment cela se compare-t-il à quelque chose comme la mise en œuvre de Jax-RS Jersey? Est-ce qu'un cadre comme le jeu courir des cercles autour de Jersey à cause de toutes ses cloches et sifflets cool, et cela repose aussi?
La productivité du développeur est importante, mais est donc une bonne implémentation. Peut-être que l'utilisation d'un cadre MVC pour le repos uniquement des services est «faux»?
Remarque, seuls les services reposants, pas de composants d'interface utilisateur du tout.
3 Réponses :
JAX-RS est une norme et des implémentations peuvent être créées par différents fournisseurs. Jersey est une telle mise en œuvre. Les autres cadres peuvent utiliser JAX-RS mais ne sont pas des normes. Donc ce n'est pas une comparaison individuelle.
Je n'ai jamais entendu parler de jouer avant, mais cela a l'air intéressant, plus semblable aux rails et à Django que Jersey. Ce que j'aime à propos de Jersey, c'est qu'il peut être intégré aux applications Web Java existantes en ajoutant simplement les pots et en déclarant certaines choses dans le web.xml. Ce que je trouve déroutant à propos de Jersey et Jax-Rs est le routage.
Jouer semble faire un routage plus facile, cependant, corrigez-moi si je me trompe, semble être un cadre tout-ou-rien et ne peut pas être utilisé aux côtés d'autres servlets dans la même application Web.
Même si ce n'est pas "faux" d'utiliser un cadre MVC pour des services reposants, il existe des avantages et des inconvénients par rapport à une implémentation JAX-RS.
(Disclaimer: Je n'ai utilisé que Jersey et jouer! Pour le plaisir, et non sur les systèmes de production de production, j'ai donc adapté mes commentaires plus généralement à MVC vs. Jax-Rs. N'oubliez pas que ce sont des généralisations générales. )
Cadres MVC - au moins ceux qui sont considérés comme développeurs conviviaux et "slick" - vous permettent généralement de créer une couche de persistance (la partie modèle ). La plupart simplifient également les demandes de «routage» à l'aide d'un échafaudage via une convention ou une forme de configuration. Les inconvénients sont que vous devez vous conformer à certaines conventions de vos contrôleurs et devez généralement écrire une vue pour chaque ressource (ou créer des couches d'abstractions pour éviter de réécrire le même code).
Jax-RS excelle à la définition du routage (à l'aide d'annotations Java) et à éliminer les restrictions sur la classe de services. D'après mon expérience, cela a considérablement réduit la quantité de code de la chaudière et de frais généraux de développement. Jersey et Apache CXF gérent également la série XML ou JSON à l'aide d'annotations JAXB, ce qui élimine la nécessité de comprendre la vue dans un contexte MVC. L'inconvénient est que vous devez comprendre votre propre couche ORM ou Persistence, qui pourrait être bonne ou mauvaise selon que vous construisez sur des données existantes ou créez un système Greenfield (ou en utilisant autre chose qu'un JPA / RDBMS. Par exemple, le magasin de données NOSQL).
Mon commentaire personnel: Jouez! est un cadre vraiment cool, mais je choisirais CXF (ou Jersey) sur un framework MVC n'importe quel jour de construire un service reposant. Dans mon expérience, cela libère le développeur de se concentrer sur la logique nécessaire au service et ouvre des options pour différentes approches de base de données. Outil droit pour le bon travail.
Sur une note plus personnelle: j'ai investi beaucoup de temps à étudier et à faire des recherches! Pour développer un cadre reposant uniquement pour continuer à fonctionner dans des limitations, des différences de version, des problèmes de documentation, etc. Jouer! A beaucoup de traits cools, mais il est suffisamment tempérament que je souhaite que je me suis plongé dans une solution Jersey / Jax-RS.
Vous pouvez utiliser n'importe quelle couche de données que vous souhaitez avec Jersey ou jouer. XML / JSON est similaire. Vous mentionnez JAXB -> Vous pouvez obtenir cela fonctionnant avec Jersey, CXF ou Jouer. Le grand facteur de décision devrait être de savoir que vous voulez travailler dans le monde Scala ou le monde de Java.
En règle générale: pour Scala, utilisez la lecture. Pour Java, utilisez Jersey.
vous peut utiliser jersey / scala et jouer / java; J'ai fait les deux. Ça marche. Ce n'est pas mauvais. Mais à moins que vous n'ayez une raison particulière de faire cela, je ne voudrais pas mélanger les écosystèmes. Java and Scala sont interopérables, mais ils ont des écosystèmes différents, j'éviterais d'ajouter Java-isms si vous utilisez Scala ou Scala-ISMS et Dépendances si vous utilisez droit Java.
Jersey et Play sont généralement proches pour les services de repos. Ni vraiment aucune trace tueuse sur l'autre.
Jersey définit des mappages URL dans les annotations, la lecture les définit dans un fichier de route de service. Et ils forment ou ont une qualité variable d'intégration avec différentes bibliothèques pour des éléments tels que XML, JSON, base de données, tests, moqueurs, bibliothèques d'injection de dépendance et déploiement de serveur d'applications.
Le monde Java a JMS, Spring, Junit, JDBI / Hibernate / JPA, Jetty / Grizzly. Le monde Scala a Akka, Spécifications2 / Scalatest, Anorm / Slick. Jersey est un meilleur ajustement pour le premier monde, Scala pour la seconde. Vous pouvez définitivement croiser cela, mais il sera un peu moins élégant et pourrait nécessiter plus de codage de colle.