Etat de l'art Java framework web pour les applications GUI RESTful? [fermé]

Question

Oui, je sais, la vieille question du meilleur cadre web ... mais laissez-moi vous expliquer.

Je cherche framework web Java Servlet allowes Interaktion RESTful et est également adapté pour construire des interfaces graphiques web.

Ce que je veux:

• Prise en charge REST avec la négociation de contenu http et agréable mappage d'URL
• conversion de données de params de demande à l'objet de domaine (et idéalement l'autre direction aussi)
• pas besoin de dupliquer objet de domaine d'interface sur le Web (comme dans struts)
• intégration facile EJB
• injection de dépendance doit être effectuée par le serveur Java EE
• Code compréhensible (je n'aime pas printemps CVM magie wirering des composants dans le chemin de classe)
• facile à configurer (ce qui est pas configuré au printemps est comme par magie fastidieux de configurer dans le conteneur - je préfère parfois les dépendances directes)
• la roue ne doit pas être reeinvented, e. g. quelque chose comme JPA et BeanValidation doit être utilisé et non réinventé par le cadre, ou au moins ces normes devrait être facile à utiliser.
• Prise en charge de validation avec affichage des erreurs dans les formulaires
• soutien à l'internationalisation

Les candidats:

• Spring MVC est puissant, mais je suis fatigué de configuration Spring et ne pas comme le modèle de programmation. Je pense qu'il est un peu trop abstraite et flexible et nécessite donc de configuration beaucoup. Et je n'aime pas la façon dont Spring MVC utilise des annotations. Mais il y a aussi quelques défauts de conception comme des méthodes qui renvoient une valeur par return et via un paramètre de sortie - vraiment laid! Je pense que ce ne serait pas facile à utiliser Spring MVC avec injection de dépendances Java EE, car Spring MVC repose en grande partie sur Spring DI.

• Roo semble être cool, mais il est juste une autre façon de créer une application Spring MVC et il fait des choses étranges avec AOP.

• Struts est un peu maladroit et outdatet.

• Stripes L'approche ActionBean ne semble pas beaucoup mieux que Struts. Je ne l'aime pas.

• Grails agréable, mais poussette (au moins avant 1,2). Reeinvents la roue: Je préfère JPA sur Gorm par exemple
.

Voir aussi 10 Meilleur Java frameworks Web

Je ne suis pas à la recherche de cadres avec l'état de l'interface utilisateur sur le serveur comme Wicket, tapisserie ou JSF. Je pense que cette approche est contraire aux principes fondamentaux du web!

Alors, que faire? Écrire un cadre à partir de zéro? hmm ...

Je voudrais avoir quelque chose comme JAX-RS avec le soutien pour le navigateur classique GUIs. Par exemple, le cadre devrait soutenir la validation et de mettre erreur de validation dans le formulaire réaffichée. Y at-il quelque chose comme ça? Les recommandations?

Answer 1

Je pense que votre caractérisation de Grails comme « buggy » est un peu dur. Bien que vous rencontrez des erreurs lors de l'utilisation Grails il est souvent les cadres sous-jacents (Spring, Hibernate) ou un plug-in qui est responsable plutôt que Grails.

En outre, étant donné que Hibernate est une implémentation JPA, ne dit-il vraiment de sens que

  

Je préfère JPA sur Gorm

Quoi qu'il en soit, si vous êtes vraiment pas satisfait de Grails ou l'un des autres cadres que vous avez mentionnés, le Jouer cadre vaut peut-être regarder.

Answer 2

J'ai blogué sur l'utilisation JAX-RS comme framework web fédérateur dans le passé . Vous pouvez faire à peu près tout ce que vous avez besoin avec JAX-RS; le principal inconvénient est toutes les pièces sont peut-être pas aussi bien documentées dans un endroit comme des choses comme Spring MVC, rayures, Grails, Seam et al.

Pour les vues, son assez facile à utiliser JAX-RS avec Jersey et web de soutien en HTML dans UIs outre les services RESTful dans JSON / XML / whatever. Vous pouvez réutiliser la négociation de contenu élégant JAXRS si les en-têtes acceptent le contenu HTTP sont utilisés pour décider si HTML ou XML est retourné etc (plus vous pouvez poids HTML sur le côté serveur pour éviter de servir XML à certains navigateurs Web qui fournissent accepter des en-têtes bizarres - je suis vous regardant Safari qui préfère XML en HTML!). par exemple. ajoutant @ImplicitProduces ( « text / html; qs = 5 ») à votre grain de ressources pondèreront HTML supérieur à toute autre représentation. Vous pouvez également configurer URI (postfixes comme l'ajout .html ou .xml ou .json) pour passer outre la négociation de contenu; ce qui fait de tester les différentes représentations dans un navigateur beaucoup plus simple.

Jersey soutient des vues implicites bien que vous pouvez rendre des vues en HTML en utilisant un moteur de modèle comme JSP ou modèles de levage ou quoi; puis utilisez les JAX-RS plus traditionnels fournisseurs de type XML marshalling / JSON. Vous pouvez être explicite avec des vues; ou laissez-JAX-RS trouver votre modèle etc.

Pour voir des vues implicites dans l'action est probablement la peine de télécharger la source de Jersey et en regardant les échantillons, tels que la librairie (recherche @ImplicitProduces si vous le souhaitez).

En termes de choses comme la validation, il est facile d'intégrer le Bean Validation JSR dans un grain de ressources; de sorte que vous pouvez effectuer une validation personnalisée d'une ressource ou DTO ou autre. De même, il est agréable de soutien de l'affichage sous forme de Jersey (sous forme de haricots).

Je recommande d'utiliser une DI / cadre IoC pour injecter les grains de ressources avec des choses dont ils ont besoin (comme la substance de base de données, des trucs de validation des haricots ou des objets de service ou autres joyeusetés). Guice fonctionne assez bien avec Jersey si vous voulez éviter Spring; si printemps avec JavaConfig n'évite beaucoup de XML.

Pour UIs complexe, vous voulez probablement utiliser JavaScript sur le client ces jours-ci. Alors que sa facilité de JavaScript pour appeler des services reposant (en particulier si elles utilisent JSON ou JSONP) - la pièce manquante réutilise avec élégance les services RESTful en Java / JAX-RS de GWT. Jusqu'à présent, RestyGWT semble le plus prometteur. Un jour, peut-être le meilleur cadre de rassemblement JSON, Jackson aura des liaisons GWT natives. L'idée serait de réutiliser des objets DTO dans GWT du côté client et côté serveur JAX-RS -. Tout en restant complètement RESTful

Answer 3

Je voudrais parler de la Restlet Framework , qui a été le premier cadre REST pour Java quand il lancé en 2005. Il est arrivé à maturité, évolutive, dispose d'une grande base d'utilisateurs et une communauté active.

La version 2.0 est en phase finale de développement et fournit un large ensemble comprenant les caractéristiques:

• cartographie complète des concepts HTTP dans une API Java propre
• API cohérente pour côté client et côté serveur
• l'intégration avec de nombreux Technos populaires (FreeMarker, vitesse, Printemps, Jackson, XStream, JAXB, Atom, OData / WCF Data Services, etc.)
• peut être déployé en mode autonome Java SE, l'intérieur du conteneur Java EE / Servlet, dans Google App Engine, Android et même GWT pour lequel il sait comment sérialiser automatiquement les haricots à l'aide différée de liaison (similaire à GWT-RPC, mais RESTful)
• fournit de nombreux connecteurs pour HTTP, SMTP, POP, JDBC, SIP, etc.
• package de sécurité complète intégrée, axée sur la sécurité web
• soutien à JAX-RS comme une extension
• API orientée classe qui est prévisible, facile à étendre et à configurer (en Java, XML, Spring, Groovy, Scala, etc.) avec prise en charge des annotations Java quand elles sont vraiment utiles
• etc.

Jetez un oeil sur le projet et lui donner un essai: http://www.restlet.org/

Answer 4

Jetez un oeil à dropwizard aussi. .

Answer 5

Il est pas sur votre liste mais je recommande resteasy pour construire votre webservices qui est assez facile à utiliser ... juste besoin d'utiliser des annotations sur les méthodes pour livrer les webservices, et aussi tout ce que vous avez écrit que tu veux.

En outre, si tu veux une bonne intégration EJB, u peut utiliser resteasy avec le Framework JBoss Seam