The Coder's Breakfast - Mot-clé - angularjs - Commentaires2022-11-22T14:44:11+01:00Olivier Croisierurn:md5:7bccc57fa40daaa0bbb47c16f3d66529DotclearRestangular : une architecture full-REST avec Restlet et AngularJS - Thomas Ponsurn:md5:8793540e1e254f115711f641893048b52013-09-21T10:30:08+02:002013-09-21T10:51:39+02:00Thomas Pons<p>En parlant de RestAngular : <a href="https://github.com/mgonto/restangular" title="https://github.com/mgonto/restangular" rel="nofollow">https://github.com/mgonto/restangul...</a></p>
<p>C'est pas mal fait et ça utilise des promises :)</p>Restangular : une architecture full-REST avec Restlet et AngularJS - Frédéric Camblorurn:md5:82234a00afebde0abb6769b569737f272013-08-13T11:30:37+02:002013-08-13T10:34:58+02:00Frédéric Camblor<p>Je me suis timeboxé à 1h pour refactorer la partie serverside en restx, visible ici pour les curieux : <a href="https://github.com/fcamblor/restangular/commits/restx" title="https://github.com/fcamblor/restangular/commits/restx" rel="nofollow">https://github.com/fcamblor/restang...</a></p>
<p>Ce qui m'a le plus surpris durant ce refactoring, c'est l'utilisation systématique des Representation. J'ai même cru au début que c'était quelque chose d'obligatoire dans restlet, et puis il y a eu la discussion sur twitter avec fabien (<a href="https://twitter.com/fcamblor/status/366854350603169792" title="https://twitter.com/fcamblor/status/366854350603169792" rel="nofollow">https://twitter.com/fcamblor/status...</a>) qui m'a rassuré sur ce point.</p>
<p>En terme de temps de démarrage, restx est perdant : 600ms vs 27ms pour restlet ... mais ça reste acceptable :-)<br />
Il faudrait bencher les temps que prennent une requête en moyenne.</p>
<p>Par contre en terme de design, j'avoue avoir quelques préférences envers restx (bon ok, je ne suis pas forcément la personne la plus objective sur le sujet ;-)) :<br />
- Très peu de réflexion (la seule réflexion utilisée est celle de Jackson pour les entrées/sorties) : aussi bien l'injection/résolution de dépendances que la déclaration des routes/paramètres se fait via de la génération de code basé sur de l'annotation processing (meilleures perfs, debugging plus aisé dans l'IDE à l'aide des "call hierarchy")<br />
- Pas besoin d'hériter de quoique ce soit pour que ça marche (dans tes exemples, souvent, tu as besoin d'hériter d'une classe : que ce soit sur l'Application ou sur les Resources)<br />
- Le fait de déclarer les routes sur chaque méthode et non de manière centralisée (comme on le fait avec spring mvc). Là, c'est plus du subjectif car il y a des pros & cons dans les 2 philosophies.<br />
- L'utilisation des Optional Guava en entrée/sortie pour définir les beans optionnels<br />
- La validation des beans via bean validation<br />
- La compilation à la volée (à la Play!), fonctionnalité à venir dans la 0.2.9 :-)</p>
<p>J'aurais aimé mettre en place davantage de choses (tests basés sur des fichiers de specs, bean validation, cache et sécurité), mais en 1h, c'était compliqué :)</p>Restangular : une architecture full-REST avec Restlet et AngularJS - Olivier Croisierurn:md5:ade95e881d8a1c88a8fa47877a1efe942013-08-13T11:07:29+02:002013-08-13T10:07:38+02:00Olivier Croisier<p>Effectivement, on ne manque pas de solutions. Mais Restlet a quelques atouts dans sa manche.</p>
<p>L'application montrée ici est simplissime, et ne tire pas partie des fonctionnaliltés avancées de Restlet, comme :</p>
<ul>
<li>Le fait qu'on peut construire un <em>pipeline</em> personnalisé (et potentiellement différent) entre le <code>Router</code> et chaque <code>Restlet</code> terminale (qui traite une requête), par exemple pour ajouter des filtres de sécurité, de logging, etc. à granularité très fine, et réutilisables (pattern Decorator).</li>
<li>Le fait qu'une Application peut être réutilisée telle quelle sur différents environnements - et j'ai montré ici que le fait de proposer un serveur embarqué léger fournissait une alternative intéressante au traditionnel couple Jetty + war, qui tire un bon paquet de dépendances.</li>
<li>Le fait que Restlet pousse à concevoir son SI comme un ensemble de ressources exposées et consommées. Une Application peut gérer les Users, une autre tout ce qui est financier, une troisième tout ce qui touche aux produits vendus... Les Applications peuvent alors être déployées sur différents Composants, ou sur le même (dans ce cas, elles peuvent communiquer directement entre elles sans repasser par toute la couche réseau).</li>
<li>Le fait qu'une Application peut être intégrée dans une application Java EE classique sur un serveur d'applications. On peut donc parfaitement faire cohabiter Spring MVC pour la partie présentation utilisateur, et Restlet pour la partie exposition des ressources en REST.</li>
<li>Le fait que Restlet peut également <em>consommer</em> des ressources REST. Le jar basique est petit et sans dépendances, et offre déjà beaucoup de services, dont le mapping Representation - Objet.</li>
</ul>
<p>Pour finir, mais c'est totalement subjectif, mon pifomètre personnel a réagi positivement à cette technologie. Comme pour AngularJS bien avant sa présentation à la JavaOne, et comme pour Spring 1.1 il y a... longtemps :) Je peux me tromper, mais disons que Restlet me paraît sain et utile.</p>Restangular : une architecture full-REST avec Restlet et AngularJS - FabienMurn:md5:2320c36aa5aebce0a5bd1211e4305d382013-08-13T09:33:27+02:002013-08-13T09:50:16+02:00FabienM<p>Article bien détaillé.</p>
<p>Néanmoins j'ai un doute : entre JAX-RS est ses implémentations (à commencer par CXF et la RI) puis avec Spring-MVC et son @ResponseBody, le moins qu'on puisse dire c'est qu'on ne manque pas de solutions en Java pour exposer des services REST.</p>
<p>Je suppose que le footprint de Restlet est plus léger qu'une stack Spring dans le cas d'une application simple, mais ça me semble être une plus value un peu juste. Y'a-t-il d'autres avantages à l'emploi de Restlet, notamment par rapport à JAX-RS ?</p>Restangular : une architecture full-REST avec Restlet et AngularJS - Olivier Croisierurn:md5:650ca45ccf84cb39c1e7047cc4e067662013-08-12T10:44:10+02:002013-08-12T09:44:19+02:00Olivier Croisier<p>@Adrien : La méthode <code>getAttribute()</code> est accessible depuis toutes les méthodes, tu n'es pas obligé de récupérer toutes les variables dans la méthode <code>doInit()</code>. C'était le pattern utilisé dans le livre, je l'ai simplement réutilisé dans mon code. Mais en pratique, ça ne devrait pas être très gênant, il est rare d'avoir plus d'une ou deux variables dans l'URL.</p>
<p>@Doanduyhai : D'après Maven, le coeur de Restlet ne tire aucune dépendance. Si tu ajoutes le support de Jackson, de Velocity, l'intégration Java EE, etc., évidemment la liste s'allonge, mais on reste loin de la gourmandise d'un Spring par exemple. Si tu ne sers que des ressources statiques (en plus des ressources REST), Restlet semble donc une solution simple, légère et pratique.<br /><br />
Pour les perfs, je n'ai pas fait de tests.</p>Restangular : une architecture full-REST avec Restlet et AngularJS - doanduyhaiurn:md5:adce636026d49dcd127e4fcff3381c4c2013-08-12T09:56:04+02:002013-08-12T09:33:09+02:00doanduyhai<p>Intéressante cette présentation. Pour mes pocs je faisais souvent du Spring MVC embarqué dans un Jetty côté serveur. Du coup avec Restlet on n'a plus besoin de server web. Par contre à titre purement d'information, qu'en est il des perf ? Est ce que Restlet est assez light et ne tire pas la terre entière en terme de dépendance maven ?</p>Restangular : une architecture full-REST avec Restlet et AngularJS - Adrienurn:md5:4f8a762ebccf8639d99eff9f8847cf402013-08-12T08:58:38+02:002013-08-12T09:33:09+02:00Adrien<p>Très bon article comme d'habitude. Une seule chose me chagrine c'est l'identifiant de la todo à récupérer. Il se trouve dans une méthode annoté de @init. Est-ce que cela veut dire que si dans la même classe j'ai plusieurs méthodes permettant de récupérer des éléments alors tous les paramètres, si différents, sont récupérés dans cette méthode pour être ajouté en tant que champ de la classe ? Cela peut rendre la classe difficile à lire et/ou debugguer, non?</p>
<p>Merci en tout cas.</p>