Robusta Web Library : Simplifiez REST et Ajax

I-A-1. Qu'est-ce que REST ?▲

I-A-2. Pourquoi REST ?▲

Le Web 2.0 permet évidemment bien plus de choses que le web 1.0. Mais c'est au prix d'une plus grande complexité, principalement liée à Ajax et aux Mash-up. REST et Robusta aident à éviter la complexité exponentielle.

Robusta Web Library (Robusta) est une bibliothèque Java spécialement conçue pour les applications REST (plus ou moins 'ful'), et pour les sites web Ajax. Robusta n'est pas un framework : il ne guide pas le déroulement des opérations, mais donne un certain nombre de solutions déclinées en packages :

• rest : resource, ResourceController, RepresentationManager : toute la terminologie REST en trois interfaces ;
• security : simplifier l'ergonomie web avec le protocole ArmyLazy tout en sécurisant les données sensibles ;
• exceptions : gérer les Exceptions en facilitant l'envoi de Code Retour Http ;
• xml : écrire et analyser rapidement les petits documents XML envoyés par les requêtes ;
• i18n : internationaliser un service web ;
• j2ee : des tags pour vous simplifier JSP.

Tous ces packages sont indépendants (mais nécessitent le package 'commons') et la plupart n'utilisent pas la terminologie REST. Robusta peut donc être utilisé dans n'importe quel environnement Java, mais il prend naturellement tout son sens dans une application Web RESTful et Ajax.

Vous pouvez donc parfaitement utiliser Robusta dans un conteneur web (Tomcat, Glassfish, JBoss), avec Spring ou Restlet.

Notez également que les classes ou packages notés Impl ou implementation sont des solutions toutes faites et piochent dans les différents packages de Robusta. Vous pouvez éviter ces classes si vous souhaitez customiser de A à Z.

Si l'on se réfère à Wikipédia, un framework est un guide de travail, ce qui suggère une tolérance plus ou moins grande à déborder de ce cadre. Un framework comme Struts a été très répandu dans l'industrie, et sa faible tolérance à l'excentricité a permis son utilisation à l'échelle industrielle, favorisant l'outsourcing.

La créativité étant source de richesse dans les hautes technologies, Spring s'est vite affirmé comme étant un Framework souple : on utilise ce que l'on veut. Restlet, quant à lui utilisé pour ses capacités REST, s'intègre avec les autres frameworks. GWT préfère parler de Toolkit pour contourner la sémantique de rigidité.

Robusta est bien une bibliothèque : un ensemble de classes et d'interfaces utilisables à n'importe quel moment de votre code. S'il s'intègre parfaitement à un contexte REST et Ajax, seul ce tutoriel propose un guide pour votre architecture. Robusta est donc une collection de raccourcis que vous allez, je l'espère, vite apprivoiser pour l'utiliser dans tout type de projets.

REST utilise beaucoup le concept de Resource, et HTTP aussi : URI signifie Universal Resource Identifier. D'après ce nom, une URI n'est pas une « adresse web » au sens géographique, mais c'est la technologie qui a imposé ce dernier sens. Inutile de revenir en arrière, et considérons qu'une Resource est un concept manipulable par des requêtes émises à destination d'une adresse.

En langage objet, ces concepts sont des classes. En UML, ce sont des éléments du Modèle du Domaine. On ne fait pas une classe pour chaque concept, aussi on ne formalise pas une Resource, en créant son URI, pour chaque concept. Mais dans le doute, cela ne fait pas de mal de créer une Resource.

Robusta définit l'interface Resource de façon à interagir avec les bases de données. Le « I » de URI signifie Identifier, et un outil de Netbeans générait automatiquement l'élément id comme étant une URI. Il est à mon sens préférable de décrire, dans une classe Java, cet identifiant comme étant une clé primaire de la base de données, et donc un Long.

public interface Resource {
    
    public static final long UNKNOWN_ID = -1995;
    public long getId();
    public void setId(long id);    
    public RepresentationManager getRepresentationManager(); 
    public String getRepresentation();
}

Comme précisé, Robusta n'est pas un framework : utilisez votre définition de Resource si vous le préférez. Robusta sera toujours utilisable, car très peu de classes utilisent robusta.rest.Resource.

Souvenez-vous de vos premiers formulaires en HTML et PHP :

    <FORM action="newuser.php" method="POST">
        <input name="username" type ="text">
        <input name="password" type ="password">
        <input type ="SUBMIT" value="Login">
    </FORM>

Vous envoyiez alors de façon mécanique une requête HTTP vers la page newuser.php. Et à chaque action, une page PHP était créée, à chaque fois en utilisant $_POST[« inputName »]. Il fallait aussi créer une page deleteUser.php, readUser.php, updateUser.php, ou passer par l'url user.php?iWantTo=delete et accumuler les isset().

Avec REST, vous feriez une page userController.php, sur laquelle on envoie une requête :

• GET pour lire le User ;;
• POST pour créer un User ;
• PUT pour modifier le User ;
• DELETE supprimer le User.

User est une Resource. La page userController.php est un ResourceController.

« Attention, je ne fais pas un Site Web, je fais une application Web » est une citation de plus en plus fréquente. Il est sous-entendu qu'un Site Web est un graphe de plusieurs pages reliées par des liens GET, alors qu'une Application Web tient en une seule page grâce à Ajax. GMail en est l'exemple le plus illustre.

Si la distinction permet de faire augmenter le tarif de la prestation, je doute qu'elle soit techniquement bien fondée. Pour fonctionner correctement, une application web n'a pas pour contrainte vitale de tenir en une page. D'ailleurs Gmail s'intègre très bien à l'Agenda, qui est situé à une autre adresse. Une Application Web est plutôt une ou plusieurs pages faisant appel à un Service Web. Si l'application est RESTful, elle utilisera, par Ajax, des méthodes PUT et DELETE que ne peut utiliser un graphe de pages.

Alors qu'une page web affiche quelque chose, un Web Service est un système client-serveur échangeant des données. À charge du client d'afficher ou non ces données.

Site web, Application web, Web service fonctionnent avec HTTP, éventuellement avec Ajax et Java et peuvent être RESTful. Je parlerais en général de Site Web, expression fondatrice, pour faire référence à ces trois concepts : vos Resources lues ou modifiées sont bien situées sur un Site identifié par une URI.

Selon les versions, les navigateurs Konqueror et surtout Safari ne gèrent pas ou mal les méthodes PUT et DELETE, ce qui n'est pourtant pas trop demander ! En conséquence, certains frameworks Prototype ou Rails utilisent POST avec le paramètre _method pour désigner la véritable méthode :

    PUT /myUri/24
devient
    POST /myUri/24
    _method:put

Pire encore ! Avec Prototype, insérer du XML dans l'option postBody de la requête va effacer ce paramètre _method. On ne peut pas penser à tout ! Il faut donc penser à écrire soi-même dans l'url le paramètre de la méthod.

Le framework ExtJs envoie lui sur demande des requêtes PUT et DELETE. Et s'il est assez facile de modifier le code source de Prototype.js pour forcer la requête PUT ou DELETE, cela ne le fera pas fonctionner ces requêtes dans les navigateurs défectueux. Prudence et tests sont de mise.

La bibliothèque Robusta permet de s'en sortir assez facilement avec l'attribut _method. Comme le fait Ruby on Rails, le tag JSP <robusta:request> détectera la méthode correcte, et les fonctions isPut() et isDelete() jouent ce rôle avec JAX-RS.

Sachez que par défaut, le navigateur enverra souvent une requête avec 'application/x-www-form-urlencoded' : c'est le content-type logique d'une balise <FORM>. Avec Ajax, il faudra changer par 'application/xml' ou 'application/json'.

En principe, la réponse sera soit 'text/html' pour du HTML, soit 'application/xml' pour du XML, soit 'application/json' pour JSON.

JSON est une syntaxe presque équivalente du xml, sans attributs ni namespace. Comme l'écriture est plus condensée, c'est par exemple une très bonne solution pour transmettre des larges listes de données. Très populaire avec Ruby, son support est assez restreint en Java et Robusta ne fait malheureusement pas exception.