Robusta : Java & RESTful Web Services » RESTful https://blog.developpez.com/java_rest Fri, 24 Dec 2010 11:23:17 +0000 fr-FR hourly 1 https://wordpress.org/?v=4.1.42 Robusta Web Toolkit : Un peu de Buzz pour REST & Java https://blog.developpez.com/java_rest/p7757/restful/robusta_web_toolkit_un_peu_de_buzz_pour https://blog.developpez.com/java_rest/p7757/restful/robusta_web_toolkit_un_peu_de_buzz_pour#comments Wed, 17 Jun 2009 10:07:09 +0000 Je finis cette semaine une première version public de Robusta Web Toolkit (RWT). Cette bibliothèque s’est construite au fil des trois dernières années lors de la construction d’Edupassion.com.

Depuis un peu plus d’un an, l’architecture d’Edupassion est passée RESTful et j’ai décidé d’épurer la biblitohèque afin de fournir un ensemble d’outils légers et cohérents facilitant les usages fréquents lors d’un processus REST. Simplicité et Productivités sont (en principe :) ) les maîtres mots.

Le premier tutoriel est en cours d’écriture, et RWT est téléchargeable dans une version qui évoluera encore un peu, l’essentiel du travail restant étant d’écrire une documentation convenable.

Vous pouvez toutefois vous amuser avec :

La version 0.9 stable et quasi définitive sera disponible au plus tard la semaine prochaine. En espérant des commentaires et peut-être quelques add-on de la communauté pour une version 1.0 en Septembre.

]]> 0 Je pense que je vais m’arrêter là https://blog.developpez.com/java_rest/p6769/restful/je_pense_que_je_vais_m_arreter_la https://blog.developpez.com/java_rest/p6769/restful/je_pense_que_je_vais_m_arreter_la#comments Tue, 11 Nov 2008 15:48:10 +0000 JPA (Java Persistence API) sera sans doute le dernier de mes joujoux technologiques pour bâtir l’architecture de la plateforme pédagogique Edupassion.com.
technologies web
Tout cela fait beaucoup de technologies pour un seul homme. Ext-JS risque d’être le point faible… et le plus visible.

Le projet est donc séparé en 6 modules :
  • Code Browser : HTML reçu par la front view, Ajax vers le web service
  • Front view (Module Edupassion) : Distribution du HTML, redirection au Web Service
  • Web Service (module wsedupassion) : http -> JSP -> Javabean -> validation -> accès données -> analyse -> résultat xml
  • Code métier (module e-library) : contient les classes School, Teacher, Student, Work, etc.
  • Accès données (module JPA+Crud) : Les classes Entities sont générées par Netbeans 6.5. Le Crud convertit ces entities en classes métiers de e-library.
  • La base de donnée : On y accède soit par les entities, soit par des requêtes JPA, et parfois par des requêtes jdbc.

JPA
La seule originalité est la séparation franche entre les Entities issues de la Bdd et les classes métiers qui en sont presque des clones. Mais pour moi il est hors de question de rajouter la moindre ligne au milieu d’un code remplit d’annotation et de requêtes à mon avis difficile à maintenir.

J’apprécie cependant énormément de faire un Crud via ces Entities plutôt que par JDBC. La maintenance est plus simple, puisque, par exemple, en renommant une colonne de ma BDD, Netbeans génèrera des classes différentes et fera remarquer une erreur dans le code de mon CRUD. Cela est impossible avec du JDBC pur.

REST
L’accès aux web service se fait par REST, via des requêtes GET, POST, PUT et DELETE. Il a fallut pour cela modifier le fichier de Prototype, ce qui n’est pas très difficile. Un Web Service RESTFul permet principalement une montée en charge du projet sereine, sans modifier le code source.

]]> 2 Servlet-Mapping : Des expressions pas très régulières https://blog.developpez.com/java_rest/p6431/restful/servlet_mapping_des_expressions_pas_tres https://blog.developpez.com/java_rest/p6431/restful/servlet_mapping_des_expressions_pas_tres#comments Mon, 22 Sep 2008 19:03:55 +0000 Le Servlet Mapping dans un serveur Web permet de rediriger une URL vers un fichier acceptant une requête : une servlet ou une page JSP.
Par exemple la requête GET /wsedupassion/account/12 sera redirigé vers la page /wsedupassion/service/account/account.jsp. Cette page JSP sera capable de traduire le ’12’ pour récupérer le compte d’index 12 et enverra donc sous forme XML les informations lié à l’utilisateur 12.

 <br />
<resource> <br />
  <class>User</class> <br />
  <id>12</id> <br />
  <lastName>Zozol</lastName> <br />
  <firstName>Nicolas</firstName> <br />
  <url>http://www.edupassion.com</url> <br />
  <subject>Computer Sciences</subject> <br />
  <school>Robusta Web</school> <br />
</resource> <br />

Mais il y a dans le Domaine d’une école, des cas plus complexes que récupérer les informations d’un utilisateur. Par exemple récupérer l’ensemble des élèves du cours 24. On utilisera la requête :
GET /wsedupassion/course/24/students

Pour connaitre le professeur de ce groupe, ce sera :
GET /wsedupassion/course/24/teacher

Pour ajouter l’étudiant 18 à ce cours:
PUT /wsedupassion/course/24/students?idstudent=18

Et pour tout connaitre de ce cours :
GET /wsedupassion/course/24/

Et pour traiter ces requête, on utilisera les pages jsp :
– /wsedupassion/service/course/course.jsp
– /wsedupassion/service/course/teacher.jsp
– /wsedupassion/service/course/students.jsp
Le serveur (Apache, Glassfish, JBOSS, …) doit donc analyser très correctement l’uri pour dispatcher vers la bonne JSP. Voici un petit tutoriel pour les bases.

En première intention, j’avais prévu :

 <br />
<servlet-mapping> <br />
        <servlet-name>course</servlet-name> <br />
        <url-pattern>/course/[0-9]+</url-pattern> <br />
</servlet-mapping> <br />
<servlet-mapping> <br />
        <servlet-name>course_students</servlet-name> <br />
        <url-pattern>/course/[0-9]+/students/*</url-pattern> <br />
</servlet-mapping> <br />
<servlet-mapping> <br />
        <servlet-name>course_teacher</servlet-name> <br />
        <url-pattern>/course/[0-9]+/teacher/*</url-pattern> <br />
</servlet-mapping> <br />

Mais les expressions régulières ne sont en fait absolument pas reconnues. Le serveur ne connnait que ‘*’ et privilégie le pattern selon 4 règles hierarchiques from outer space :
– Il préfère le pattern exact :/wsedupassion/account plutot que /wsedupassion/*
– Il préfère le pattern le plus long : /course/12/teacher/ plutot /course/*
– Il préfère les xyz/* (chemin) plutôt que *.xzy (type de fichier)
– Il choisit / si cette servlet racine existe

Et sinon le serveur envoit l’erreur 404( Source).

Mon fichier web.xml ressemblera donc à :

 <br />
<servlet-mapping> <br />
        <servlet-name>course</servlet-name> <br />
        <url-pattern>/course*</url-pattern> <br />
</servlet-mapping> <br />
<servlet-mapping> <br />
        <servlet-name>course_students</servlet-name> <br />
        <url-pattern>/course/*/students/*</url-pattern> <br />
</servlet-mapping> <br />
<servlet-mapping> <br />
        <servlet-name>course_teacher</servlet-name> <br />
        <url-pattern>/course/*/teacher/*</url-pattern> <br />
</servlet-mapping>

De quoi faire hurler tout prof de fac tatillon sur ses expressions régulières. Mais c’est à priori suffisant pour fonctionner, et en plus intuitif. Que demande le peuple ? Apparemment plus, puisque ca ne fonctionne pas. Deux ‘*’, ca fait beaucoup.
/school/*/student/ n’est pas différencié de /school/*/teacher et renvoient d’ailleurs toutes les deux une erreur 4004 !

Pour dispatcher des uri un peu sophistiquées, il faudrait donc
– un servlet-mapping vers un dispatcher
– le dispatcher analyse l’uri
– on forward la requete vers une autre servlet

Je n’aime pas du tout ce mélange des genres : le servlet mapping a pour objet de rediriger, et devoir faire à la main une redirection dans le processus de redirection via des classes barbares comme un RequestDispatcher. Beurk ! Quelqu’un a mieux ?

Sinon, autant garder l’uri de la JSP. Et tant pis pour les dogmes !

]]> 1 Un Blog sur le web RESTful https://blog.developpez.com/java_rest/p4823/restful/un_blog_sur_le_web_restful https://blog.developpez.com/java_rest/p4823/restful/un_blog_sur_le_web_restful#comments Sun, 20 Jan 2008 16:57:31 +0000 Les RESTful Web Services sont un des moyens d’accès à des données par Internet. Supposons que vous demandiez à un serveur l’ensemble des lycées français présents aux USA : il existe une infinité de façons pour votre navigateur web de faire cette demande, et, pour le serveur, une infinité de façons de vous répondre.
Afin de se repérer parmi ces solutions, les programmeurs ont développées plusieurs méthodes plus ou moins standardisées, et notamment des méthodes appelées RPC, SOAP ou REST. On appellera un Service Web RESTful si il englobe la grande majorité des bons conseils de Roy T. Fielding, l’inventeur de REST.

Quelle est, au premier abord, la distinction de REST ?

Lorsque vous faites une requete RPC, SOAP ou REST à un serveur, vous incluez bien sûr par cette requete ce que vous demandez au serveur. En utilisant REST, cette demande est facilement décryptable par un être humain.
Par exemple DELETE edupassion.com/webservice/professeur.jsp?id=12 effacera le professeur n°12 inscrit à Edupassion.


Pourquoi REST ?

Les avis entre l’utilisation de REST et les méthodes SOAP et RPC sont partagées. Je ne ferais pas un xe débat, mais apparemment REST a gagné la guerre. A mon avis, le principal avantage de REST est de garder un code compréhensible et que l’on peut écrire humainement à la main, alors que SOAP requiererait l’assistance d’un EDI et fournirait par là-même ce que l’on appelle du XML Nightmare. Mais comme toute solution, REST et SOAP ont leurs avantages et inconvénients. Le but de ce blog n’est donc pas de départager, mais de savoir comment utiliser REST au mieux, selon les situations. Rest vs SOAP

L’environnement du Blog

Je donnerai beaucoup d’exemples liés au site web Edupassion.com et son framework Robusta que je développe pour mon entreprise Robusta Web. Ce code sera principalement en Java, mais aussi en XML, XSLT, Javascript, JSP, etc. Je publierai aussi de temps en temps l’astuce du jour, dans n’importe quel langage. ]]> 5