Adaptive Labs est une société qui réalise des applications web et mobiles centrées sur les utilisateurs. Cela signifie que nous nous concentrons sur les besoins, les volontés, les contraintes et les sentiments des utilisateurs à chaque étape de la conception.

Adaptive Labs a 4 activités principales :

• Applications : nous créons des applications utiles, faciles à utiliser et rapides, qui exploitent pleinement les plateformes
• Consulting : nous aimons notre travail et nous aimons le partager, donc nous pouvons vous aider à créer vos propres applications et définir vos propres stratégies
• Support : nous travaillons dur pour vous fournir un support client rapide quand vous avez besoin d’aide avec nos applications
• Veille technologique : nous passons 15% de notre temps à effectuer de la veille technologique pour découvrir et vous apporter des solutions innovantes

Vous l’aurez deviné, la première création d’Adaptive Labs est… Rss Runner ! Qui, au passage, vient de passer la barre des 700 000 téléchargements.

J’avais, dès cette annonce, effectué une demande de compte sur la page dédiée. Imaginez donc ma joie lorsque j’ai découvert il y a 2/3 jours dans ma boîte de réception un e-mail intitulé “An invitation to Google Wave Developer Sandbox” ! J’ai donc gracieusement été invité à tester Google Wave, et j’en remercie vivement l’équipe Google Wave. Et, impatient comme un gamin, je ne me suis pas fait prier pour démarrer mes tests !

Avant toute chose, si vous souhaitez savoir ce qu’est Google Wave, je vous renvoie à ma petite présentation. Voici un premier bilan de mes deux premiers jours de test.

Constat n°1 : Ouf, j’avais bien compris les concepts de Google Wave !

J’ai en effet pu confirmer mon interprétation des notions et objectifs de l’outil Google Wave que j’avais présentés dans mon article après avoir étudié les vidéos et les slides diffusés par Google. Et donc, naturellement, mon grand intérêt à son égard, aux niveaux personnel et professionnel.

Constat n°2 : L’application Web fonctionne bien… Dans l’ensemble !

L’application Web, la composante “Produit” de l’outil Google Wave, est une sorte de GMail dopé. Elle fonctionne déjà bien dans son ensemble car elle permet de créer et manipuler des Waves avec des milliers d’autres participants du monde entier. Sa fluidité varie beaucoup : parfois très agréable à utiliser, elle l’est bien moins dans les périodes de grande activité. En effet, beaucoup de Waves atterrissent et évoluent dynamiquement dans notre boîte de réception car elles sont rattachées au groupe rassemblant tous les utilisateurs.

Il y a bien entendu des fonctionnalités non encore développées ainsi que de nombreux bugs mais cela ne fait que confirmer que la phase de maturation de ce produit va être longue. Ce serait de toute façon le cas puisque ce produit apporte une nouvelle façon de communiquer et de collaborer.

Constat n°3 : Concernant les “vraies nouveautés”

Quand je parle d’une “nouvelle façon de communiquer et de collaborer” : certains m’ont demandé quelles étaient les “vraies nouveautés” de cet outil, avec une certaine réserve due au fait que beaucoup des fonctionnalités de Google Wave existent déjà dans d’autres outils plus simples qui sont aujourd’hui largement utilisés. Je ne détaillerai pas ce point que j’avais largement décrit dans ma petite présentation, mais je rappellerais tout de même que Google Wave n’est pas révolutionnaire parce qu’il propose toutes ces fonctionnalités, mais parce qu’il les rassemble et les unifie de manière cohérente, autour de la notion de Wave.

Constat n°4 : Des extensions faciles à utiliser et à implémenter

Plusieurs extensions existent déjà et sont agréables à utiliser. Même si parfois, les robots ne fonctionnent plus pendant quelques minutes. N’oublions pas qu’il s’agit d’une version de test !

J’ai voulu essayer d’implémenter une extension : il m’a fallu exactement une heure pour implémenter mon premier robot ! Pour rappel, un robot est un participant automatisé qui interagit avec les Waves et leurs participants : il s’agit en fait d’une application Google App Engine qui, une fois invitée à une Wave, réagit à des événement de type “un texte a été saisi par un participant” ou “un nouveau participant a rejoint la Wave”.

Mon robot, que j’ai nommé Dr. Maps, réagit simplement à des commandes du type /map adresse afin d’insérer dans une Wave la carte Google Maps associée à cette adresse. J’ai été frappé par l’engouement des utilisateurs de Google Wave : en un jour j’ai déjà reçu 67 e-mails de personnes intéressées par mon robot, dont beaucoup me font part de leurs idées pour l’améliorer !

J’ai donc créé un espace Web dédié à ce robot : http://code.google.com/p/golden-waves/.

L’avenir nous dira ce qu’il adviendra de ce modeste robot !

En conclusion

Pour une fois je ferai court : il se passe quelque chose. Ce Google Wave ne laisse pas ses utilisateurs indifférents. Pour en être convaincu, il suffit de se perdre dans les centaines de Waves déjà créées dans le sandbox : beaucoup y voient des intérêts personnels (organisation de rendez-vous au restaurant ou au cinéma, partage de photos de vacances…) mais beaucoup d’autres y voient des intérêts professionnels (partage d’informations multi-sources, communication et collaboration homogènes…)

Il se passe quelque chose, donc. Mais concrètement, il est trop tôt pour prendre la pleine mesure de cet outil.

Dans cet esprit, j’ai initié sur le blog d’Aeon Consulting une série d’articles dont l’objectif est de définir ce qu’est vraiment REST en une dizaine de points. Les premiers concernent les notions de Ressource, URI et Adressabilité. Tout est là : http://www.aeon-consulting.fr/fr/blog/tag/rest/.

N’hésitez pas à donner votre avis, ces articles sont faits pour échanger !

Cet humble post s’adresse à ceux qui m’ont demandé de leur faire une mini-présentation de Google Wave, ainsi qu’à ceux qui n’ont pas le courage de regarder la démonstration qui a été présentée au Google IO, qui dure tout de même 1h20. On trouve en effet beaucoup d’articles qui traitent de Google Wave et des concepts associés, et il est difficile de s’en faire une idée claire car ces concepts sont réellement novateurs.

Les origines de Google Wave

Avant de rentrer dans le vif du sujet, il me semble essentiel de comprendre l’idée à l’origine de Google Wave. Je préfère citer Lars Rasmussen (qui est très clair à ce sujet) plutôt que de le paraphraser. Lars et Jens Rasmussen, les deux frères à l’origine de Google Maps, sont partis du constat suivant il y a moins de trois ans :

“[Jens] pointed out that two of the most spectacular successes in digital communication, email and instant messaging, were originally designed in the ’60s to imitate analog formats — email mimicked snail mail, and IM mimicked phone calls. Since then, so many different forms of communication had been invented — blogs, wikis, collaborative documents, etc. — and computers and networks had dramatically improved. So Jens proposed a new communications model that presumed all these advances as a starting point [...]“

Ils ont donc alors démarré un projet nommé “Walkabout” afin de donner vie à ce fameux “nouveau mode de communication”. Lars Rasmussen résume leur démarche en trois questions :

“Why do we have to live with divides between different types of communication — email versus chat, or conversations versus documents?

Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum? How simple could we make it?

What if we tried designing a communications system that took advantage of computers’ current abilities, rather than imitating non-electronic forms?”

Ainsi, après plus de deux ans de travail, le projet Walkabout a pris vie, a été rebaptisé Google Wave, et a été présenté au grand public le 28 mai 2009.

Google Wave au premier abord

Le site officiel présente Google Wave de la manière suivante :

“Google Wave is a new tool for communication and collaboration on the web”

Google Wave propose en effet une application Web dont l’interface n’est pas sans rappeler GMail :

On retrouve en effet une présentation en colonnes avec un menu, une liste de contacts, une boite de réception et un cadre de visualisation de l’élément sélectionné dans la boite de réception.

Sauf que là, la boite de réception ne contient plus des e-mails mais des Waves.

Une Wave, c’est quoi ?

Une Wave est une entité à mi-chemin entre une conversation et un document. Cette entité est partagée par un ou plusieurs participants, qui peuvent être des humains ou des robots. Vous créez une Wave, ajoutez des participants et cette Wave peut être ensuite modifiée par les participants en temps réel :

“The wave is a dynamic entity which contains state and stores historical information. A wave is a living thing, with participants communicating and modifying the wave in real time.”

Que signifie “modifier une Wave” ? Tout simplement taper du texte riche ou ajouter des photos, des vidéos ou même des gadgets (une carte par exemple). De quelle manière ? En insérant une réponse ou en éditant la Wave directement.

Jusqu’ici, “rien d’extraordinaire” me direz-vous. Sauf que Google Wave supporte les modifications concurrentes des Waves : vous voyez la Wave évoluer en temps réel lorsque d’autres participants la modifient, caractère par caractère ! Ce nouveau mode de communication et de collaboration unifie donc les messageries instantanée (chat) et persistante (e-mail) au sein d’un concept plus avancé.

Les Waves, une nouvelle façon unifiée de communiquer et de collaborer avec ses contacts

Comme l’explique Lars Rasmussen dans sa démonstration au Google IO, on passe donc d’un mode de communication “point à point” (les e-mails) à un mode centralisé (à la façon d’un bus) : les participants participent aux Waves dès leur création ou au cours de leur vie. Ainsi, les participants peuvent visualiser les modifications des Waves :

• en temps réel, dans le cas de modifications par d’autres participants connectés
• en playback, dans le cas de modifications effectuées par des participants connectés ou non

La démonstration de cette fonctionnalité de playback est impressionnante. L’idée derrière cette fonctionnalité est simple, il s’agit d’indiquer aux participants :

“Who said what and when”

Les participants peuvent donc visualiser l’historique des modifications, modification par modification, d’une manière animée ou par clics successifs.

Google Wave, une “simple” application Web ?

En fait, l’application Web décrite précédemment n’est qu’un des trois éléments qui constituent Google Wave, les trois “P” : il s’agit du Produit. Google Wave, c’est également une Plateforme et un Protocole.

Un Produit

L’objectif de l’application Web Google Web, c’est-à-dire du Produit, vous l’avez compris, est de permettre d’accéder aux Waves et de les éditer. Cette application a été développée en GWT et repose sur des apports de HTML 5.

Les intéressés pourront découvrir ces fameux apports de HTML 5 dans ce post très clair de Tim O’Reilly, mais on peut en retenir au moins un : pour effectuer l’upload d’un fichier, avec HTML 5, on n’est plus obligé de passer par l’habituel bouton “Parcourir”. On peut par exemple le faire via un drag and drop du fichier depuis l’explorateur vers une zone de la page HTML. Cet apport est largement exploité par Google Wave, notamment lors de l’attachement de fichiers à une Wave. La démonstration montre ainsi l’insertion de plusieurs images dans une Wave grâce à un seul drag and drop.

Une Plateforme

Google Wave, c’est également une Plateforme ouverte et extensible constituée de plusieurs APIs :

• Embed : API JavaScript permettant d’intégrer des Waves dans des pages Web, des blogs, etc.
• Extensions : APIs permettant de créer des extensions à l’application Web. Ces extensions sont faites pour travailler au sein des Waves.

Un Protocole

Google Wave, c’est enfin un Protocole ouvert spécifiant le stockage et l’échange des Waves, en gérant les accès concurrents. Pour plus d’informations concernant ce protocole, consultez le site officiel.

Notons que le code de Google Wave sera Open Source. L’objectif de Google est de le faire adopter par le plus de monde possible. Ainsi chaque entreprise pourra installer son propre Google Wave : on est loin de l’image de “Big Brother” si souvent attribuée à Google (néanmoins compréhensible concernant certaines applications)…

Quelques mots sur les Extensions Google Wave

Les Extensions peuvent être de deux natures : il y a les Gadgets et les Robots.

Gadgets

Les Gadgets sont des extensions côté client afin d’enrichir l’IHM des Waves. Elles peuvent bénéficier des interactions multi-utilisateurs (pour créer des jeux multi-joueurs par exemple). Notons que les Gadgets iGoogle et OpenSocial fonctionnent sur Google Wave, ce qui apporte des milliers d’applications d’entrée de jeu.

Exemples de Gadgets présentés :

• Are you coming? : permet de mettre en place un sondage dans une Wave
• Maps : permet une collaboration sur une carte Google Map au sein d’une Wave

Robots

Les Robots sont des extensions côté serveur afin d’automatiser des tâches. Il s’agit de participants à des Waves qui peuvent en modifier le contenu, interagir avec d’autres participants, ou encore transmettre de l’information à d’autres Waves ou au monde extérieur.

Exemples de Robots présentés :

• Tweety : synchronisation d’une Wave avec Twitter
• Bloggy : synchronisation d’une Wave avec un blog
• Un robot qui affiche une liste de suggestions lors de la saisie
• Un robot de correction automatique lors de la saisie (qui repose comme le précédent, apparemment, sur le Web et non sur un dictionnaire lexical “statique”). La démonstration nous le montre par exemple capable de remplacer le phrase tapée “Icland is an icland” par “Iceland is an island”, au fur et à mesure de la saisie !
• Un robot qui détecte “intelligemment” les liens lors de la saisie
• Un robot qui transforme une Wave en un outil de reporting de bugs
• Et surtout, Rosy, un robot de traduction lors de la saisie : je vous invite à regarder la fin de la démonstration, elle est vraiment impressionnante. En effet, on y voit qu’il suffit d’inviter le robot de traduction à la Wave puis de taper une phrase en Français pour que le robot la traduise en Anglais, au fur et à mesure de la saisie ! J’ai tout de même hâte de tester ce robot moi-même afin de voir si l’outil dépasse réellement les outils de traduction actuellement proposés…

Revenons à nos Waves : une Wave, ce n’est “que” cela ?

En fait, il y a un découpage fin : une Wave rassemble des Wavelets. Par exemple, lorsque vous entamez une discussion privée avec un participant particulier au sein d’une Wave rassemblant plusieurs participants, cela crée des Wavelets privées au sein de cette Wave (en plus des autres Wavelets partagées avec les autres participants).

Ces Wavelets rassemblent elles-mêmes une hiérarchie de blips. Une blip consiste en l’unité de base des conversations et leur contenu est un document.

Voilà, vous connaissez tout le vocabulaire ! En fait l’utilisateur n’a pas à connaître cette terminologie, mais elle est essentielle pour le développeur. Elle est donc clairement définie dans la documentation de l’API.

Notons également que vous pouvez attacher des tags à vos Waves, ou les relier entre elles par du drag and drop.

Un peu de recul…

Ceux qui m’ont demandé de leur présenter Google Wave m’ont parfois demandé s’il ne s’agissait pas d’un énième outil à la Twitter, Facebook, E-mail, IM, Wiki, etc. En fait, Google Wave est un outil centralisé pour toutes vos communications et rassemble d’une certaine manière tous ces outils en un seul. Et, nous l’avons vu, c’est un outil extensible et ouvert.

Cette ouverture est essentielle : Google Wave et ses trois “P” est un outil révolutionnaire tant il change notre façon de communiquer et de collaborer. Tellement révolutionnaire que son succès n’aura lieu que s’il est largement adopté. C’est pour cela que son ouverture est essentielle.

Je suis plutôt optimiste quant à son succès à moyen/long terme : sa flexibilité et son ouverture le rendent “facilement” intégrable au sein du SI. En effet, il semble destiné à remplacer tous nos outils habituels, mais d’ici là il peut s’intégrer avec chacun d’eux afin d’en être complémentaire.

En tout cas, vivement son ouverture au public ! Il semble qu’il reste quelques soucis à régler sur les autres navigateurs que Google Chrome : notamment sur les terminaux Mobiles (Androïd et iPhone). Car oui, Google Wave s’adresse également à ce monde là !

Enfin, il est clair que Google Wave ne laisse pas indifférent alors qu’il est tout juste annoncé. A titre d’illustration, le fameux cabinet Gartner y a déjà consacré deux posts dont un sur les bases algorithmiques de Google Wave (notamment l’OT, ou Operational Transformation, la théorie à la base de la gestion des accès concurrents de Google Wave). De mon côté, je pense que ce n’est pas mon dernier article sur le sujet…

• certains veulent essayer de comprendre ce qu’est vraiment REST : j’ai déjà commencé à apporter ma modeste contribution sur le sujet et je suis loin d’avoir dit mon dernier mot sur le sujet ! Je compte dès que possible y consacrer encore quelques posts bien précis…
• d’autres exposent des APIs qu’ils présentent comme RESTful : Google, Yahoo, Twitter, Facebook, E-Bay, Flickr pour ne citer qu’eux… C’est à eux que je veux consacrer ce post.

En effet, ces acteurs prépondérants de la sphère du Web 2.0 sont de facto des référents dans les technologies qu’ils mettent en avant : s’ils exposent des APIs en les déclarant RESTful, il est bon pour le “commun des mortels” de savoir si tel est vraiment le cas. Les aspects théoriques de REST sont déjà suffisamment difficiles à appréhender, alors si les exemples pratiques mis en avant ne sont pas de bons exemples, comment s’y retrouver ?

Prenons quelques exemples d’API dites RESTful au hasard (le hasard étant ici représenté par les trois premières pages de résultats d’une recherche Google sur l’expression “REST API”).

Exemple n°1 : E-Bay

Je n’ose pas m’aventurer dans les méandres de cette documentation plutôt austère. Cependant on repère rapidement un anti-pattern REST de base : dans les requêtes, le nom du service à invoquer est porté par un paramètre HTTP nommé “callname” et non par la méthode HTTP :

http://open.api.ebay.com/shopping?callname=FindItems&…

En outre, on dispose d’un point d’entrée unique mais la notion de ressource n’apparaît pas vraiment.

Exemple n°2 : Twitter

Dans ce cas, la documentation est bien plus simple et attrayante. Elle repose a priori sur un découpage en ressources (timeline, status, user…) sauf que là encore le nom du service est transmis dans l’URI et non via la méthode HTTP :

http://twitter.com/statuses/destroy/12345.json

Ainsi on envoie une requête POST sur cet URI au lieu d’une requête DELETE sur un URI de la forme suivante :

http://twitter.com/statuses/12345

En outre, le format des représentations est lui aussi indiqué dans l’URI (voir le “.json”) au lieu de profiter des puissants mécanismes de négociation de contenu fournis par HTTP. Ceci dit, les réponses retournées semblent proposer quelques URIs (n’oublions pas l’importance de l’hypermédia).

Exemple n°3 : Flickr

La documentation de l’API rappelle celle de Twitter par sa clarté et son découpage par ressources. Et là encore, le nom du service à invoquer est porté par un paramètre HTTP, nommé “method” et non par la méthode HTTP :

http://api.flickr.com/services/rest/?method=flickr.test.echo&…

Point intéressant, cette documentation donne sa propre vision de REST :

“REST est le format de requête le plus simple à utiliser”

Nous reviendrons plus tard sur cett vision de REST.

Exemple n°4 : Google

Là on est bien plus proche des principes de REST même si la notion de ressource ne ressort pas clairement :

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=REST

En effet, l’URI /search/web fait davantage penser à une opération qu’à une ressource.

Exemple n°5 : Facebook

Il s’agit là encore d’un exemple d’API similaire aux précédentes, sur la transmission du nom du service et sur l’utilisation des seules méthodes GET et POST du protocole HTTP. Cependant la documentation se veut plus pragmatique :

“The API uses a REST-like interface. This means that our Facebook method calls are made over the internet by sending HTTP GET or POST requests”

On retrouve la vision de REST comme format de requête plus simple. Autre point intéressant, l’API est présentée comme REST-like et non comme RESTful, ce qui est déjà plus rigoureux (bien que moins marketing).

Exemple n°6 : Yahoo

Les APIs proposées par Yahoo sont assez proches des précédentes :

http://address.yahooapis.com/v1/action?format=format&params

où “action” désigne le nom du service à invoquer. On retrouve donc les mêmes anti-patterns concernant la transmission du nom du service et du format des représentations. Et un autre : le numéro de version du service est indiqué dans l’URI.

Yahoo met en avant la même vision de REST que ses confrères :

“The Yahoo! Search Web Services are all REST services. That means you can easily construct request URLs that will work in your browser, on the command line, and in your code”

Un peu de recul

Les APIs étudiées violent grosso modo les mêmes principes de REST. Ces anti-patterns tournent notamment autour de la notion d’URI qui est mal exploitée : l’URI est souvent utilisé comme fourre-tout permettant par exemple d’indiquer le nom du service à invoquer, sa version, ou le format des représentations, sans même faire apparaître la notion de ressource. Alors que l’URI a pour simple objectif d’adresser une ressource (n’oublions pas la définition de ce sigle : “Uniform Resource Identifier”) et que le protocole HTTP dispose de moyens efficaces pour gérer toutes les autres problématiques évoquées (notamment : interface uniforme, négociation de contenu).

Si vous avez tenu jusqu’ici alors je vous félicite et je vous remercie. Mais ne vous arrêtez pas là ! A ce stade vous devez penser que je ne jure que par REST mais je n’ai aucunement la prétention de rejeter toutes ces APIs. Si de tels éditeurs partagent les mêmes anti-patterns REST, c’est qu’il y a une bonne raison. Et cette raison, je la partage !

En effet : effectivement, toutes ces APIs ne respectent pas toutes les contraintes imposées par REST. Mais cela les rend-elles moins flexibles, moins scalables, moins simples à utiliser ? Non, pas nécessairement. En un mot il faut du pragmatisme ! Il est clair qu’aujourd’hui tout éditeur qui se veut “high-tech” se doit de proposer une API dite “RESTful” pour des raisons marketing évidentes. Même si cette API est en réalité plutôt “REST-like” comme osent toutefois le préciser certains d’entre eux. C’est la simplicité qui est et qui doit être (justement) mise en avant et il ne faut simplement pas tomber dans le piège tendu par le marketing.

Toutes ces APIs ne sont pas RESTful. OK. Mais en pratique cela ne nuit pas à leur succès. Une API RESTful a des avantages. Mais cela ne signifie pas que seules les APIs RESTful ont ces avantages. En outre, je vous mets au défi de trouver une API réellement RESTful

Dans cette synthèse de plusieurs années d’expérience en la matière, tous les navigateurs classiques sont passé au crible : Internet Explorer 6 et 7, Firefox 2 et 3, Safari, Opera, Chrome, et même le navigateur embarqué dans Android. Tout y passe : HTTP, URI, HTML, CSS, etc. Les points abordés sont plus ou moins techniques mais tous sont intéressants. Comme on pouvait s’y attendre, les différences entre navigateurs sont très nombreuses et parfois surprenantes ! Ce livre est une véritable mine d’or pour ceux qui doivent assurer la sécurité de leurs applications, mais également pour ceux qui souhaitent comprendre le fonctionnement des navigteurs : dès la première section sur les concepts de base on est plongé dans un univers qui nous fait rapidement comprendre que la bataille des navigateurs n’est pas prête de s’arrêter…

Merci au site “Programmez.com” pour l’information.

jQuery ayant vraiment le vent en poupe, j’étais persuadé que Smashing Magazine allait présenter quelques unes de ses possibilités. C’est chose faite, avec une liste de 45 techniques permettant d’améliorer l’expérience utilisateur. Même les experts en jQuery y verront quelques bonnes idées à prendre : comme je le dis souvent, le JavaScript a donné beaucoup de moyens pour améliorer l’ergonomie des applications Web classiques, mais également beaucoup de moyens pour la réduire !

Il nous ramène d’abord dans le passé afin de nous rappeler ce qui a permis selon lui le succès d’AJAX : l’apport de réactivité et d’interactivité dans les applications Web. Comme il le dit :

“This bridged us from pages to apps”

Il s’agit là d’une idée à laquelle j’adhère également. Mais il y a selon moi une autre raison, d’ordre technique : AJAX a permis une véritable séparation entre les données et leur présentation. Cela a ouvert la voie à une infinité de nouvelles architectures. Je ne détaillerai pas ces deux idées dans ce post : j’en ai eu l’occasion aux Valtech Days, vous aurez donc tout le loisir de savoir ce que j’ai en tête sur le sujet lorsque les vidéos seront en ligne.

Ensuite, Dion Almaer nous présente les directions qu’il envisage pour l’avenir AJAX-ien : il nous rappelle d’abord les progrès qu’il y a encore à accomplir en terme de productivité. Puis il nous invite à arrêter de réfléchir aux habituelles questions de choix de frameworks pour se concentrer sur les nouveaux facteurs AJAX-iens d’enrichissement des applications Web :

“We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences. Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications”

Il évoque ainsi Comet, HTML 5 et les clients Web tactiles. J’adhère à son invitation à prendre du recul et je suis tout aussi intéressé que lui par ce que va devenir AJAX. Par contre, plutôt que de penser aux évolutions d’AJAX seul, dans mes réflexions sur l’avenir je préfère repositionner AJAX face aux technologies RIA comme Flex ou Silverlight. Surtout à l’approche de l’année 2009 qui pourrait bien être une année charnière pour toutes ces technologies… Et là encore, je vous renvoie à ma dernière présentation aux Valtech Days

Cette nouvelle version apporte notamment :

• Une meilleure gestion des documents WADL : si l’intérêt de cette spécification dans le cadre de REST est remise en cause par certains (dont je fais partie… En partie !) elle en intéresse toutefois plus d’un alors cette nouveauté restlet-ienne est à relever.
• Une extension implémentant la spécification JAX-RS (Java API for RESTful Web Services), aussi connue sous le nom de code JSR 311. Rappelons que la version finale de cette JSR est parue le 10 octobre dernier. Il s’agit là d’une évolution intéressante, même si à titre personnel je n’approuve pas forcément l’utilisation massive des annotations imposée par cette spécification.
• Un module pour GWT permettant de faire communiquer le front-end et le back-end de votre application grâce à REST sans avoir à en implémenter les couches basses vous-mêmes.
• Une extension permettant divers modes d’intégration avec Spring.

Je n’ai pas encore testé cette nouvelle version mais j’en ai hâte car :

• Restlet est le framework REST que je préfère parmi les quelques-uns qui existent : parmi ses qualités, j’apprécie depuis longtemps sa facilité de mise en œuvre, ses nombreuses extensions et sa documentation claire et concise. Mais il a également ce formidable avantage de vous permettre de (et même de vous amener à) vous concentrer sur la conception orientée ressources que nécessite la mise en place d’une architecture REST. Tous les frameworks REST n’ont pas cette qualité et il s’agit d’un point important car cette conception n’est pas toujours triviale.
• Jusqu’ici j’avais principalement deux regrets : D’abord la non implémentation de la spécification JAX-RS. Ensuite, la non intégration aisée avec Spring. En effet, étant un vrai aficionados de ce framework, j’avais assez rapidement développé ce qui me fallait pour utiliser facilement Restlet avec Spring : a minima, la déclaration et la configuration des restlets via un fichier de configuration Spring. Or cette nouvelle version semble fournir une solution à ces deux “problèmes”.

À suivre, donc… En tout cas, bravo à Jérôme Louvel et son équipe !

Avant de parler de ces deux posts, je vous invite à lire l’Introduction à REST et aux ROA que j’avais écrite il y a un an pour le blog Valtech : si vous ne connaissez pas REST, j’espère que cet article vous aidera à mieux comprendre les posts de Roy Fielding…

Aux Valtech Days, j’ai eu des échanges très intéressants sur REST avec plusieurs personnes : j’ai notamment été très heureux de rencontrer des personnes ayant comme moi mis en œuvre ces principes au sein de projets concrets, et de constater que nous partagions certaines idées pourtant méconnues ou sous-estimées. Pour résumer, concevoir une architecture RESTful, ce n’est pas uniquement exposer des services via HTTP : il y a plusieurs règles à respecter. En particulier :

1. Faire du REST, c’est utiliser tant que possible le protocole HTTP de manière standard afin de garantir la généricité des interfaces des services.

2. Faire du REST, c’est s’affranchir de la nécessité d’une description préalable des services : pour cela, il ne faut pas sous-estimer l’importance des liens hypertextes et des types de représentation des ressources.

3. Faire du REST, c’est repenser son SI en termes de ressources : si ce n’est pas toujours trivial (loin de là !), il s’agit d’un exercice très enrichissant.

Alors imaginez ma hâte lorsque j’ai découvert un post de Roy Fielding qui commence par la phrase suivante :

“I am getting frustrated by the number of people calling any HTTP-based interface a REST API”

Dans ce post du 20 octobre, il rappelle une série de règles non intuitives mais essentielles lorsqu’on conçoit une architecture RESTful. Ces règles rejoignent les trois points que j’ai évoqués.

1.  L’importance de l’utilisation standard du protocole HTTP pour assurer la généricité des interfaces

“A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols”

En effet, le problème est que bien souvent, des modifications à ce niveau sont révélatrices d’un design des interfaces qui est spécifique aux objets manipulés : les interfaces ne sont alors plus génériques.

2. La non-nécessité d’une description préalable des services et l’importance des liens hypertextes et des types de représentation des ressources

Il ne faut pas sous-estimer l’importance des types de représentation des ressources. Le client d’un service REST ne doit pas avoir besoin d’une description préalable du service, il doit pouvoir s’appuyer sur les types de représentation des ressources :

“A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type”

On me demande souvent de quelle manière les types de représentation des ressources peuvent-elles permettre au client de déterminer quelles opérations il peut effectuer sur quelles ressources. J’aime assez les exemples donnés par Roy Fielding dans l’un de ses commentaires :

“media type tells the client either what method to use (e.g., anchor implies GET) or how to determine the method to use (e.g., form element says to look in method attribute)”

Ces exemples sont appliqués au cas d’un client interprétant du HTML, mais on peut aisément les généraliser.

Il ne faut pas non plus sous-estimer l’importance des liens hypertextes. Le client d’un service REST ne doit pas avoir besoin d’une description préalable du service, c’est également en suivant les liens hypertextes proposés dans les représentations des ressources qu’il pourra déterminer quelles opérations il peut effectuer sur quelles ressources :

“A REST API should be entered with no prior knowledge beyond the initial URI [...] From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations.

En effet, les transitions doivent être permises par les liens hypertextes et non par des informations descriptives situées hors des représentations des ressources. Ce point, souvent occulté, est sujet à de nombreuses discussions entre les défenseurs de REST et ceux qui n’acceptent pas l’idée de ne pas se reposer sur une description des services (comme le WSDL le permet avec les services WS-*).

En fait, les représentations des ressources doivent être auto-descriptives, le client d’un service REST n’a pas à savoir quelle est la nature d’une ressource, il ne fait que manipuler une de ses représentations grâce aux liens hypertextes :

“Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links”

Lorsqu’on conçoit un service RESTful, il faut arriver à faire évoluer notre vision du modèle classique Request/Reply : si le client émet une requête afin d’obtenir des représentations de plusieurs ressources, la réponse du service ne doit pas contenir un ensemble de représentations (comme dans le modèle traditionnel), mais un ensemble de liens permettant d’accéder à chacune de ces représentations :

“Query results are represented by a list of links with summary information, not by arrays of object representations”

3. Sur la difficulté de concevoir une Architecture Orientée Ressources

En lisant ce post de Roy Fieding, on réalise la difficulté de concevoir des services RESTful. Ceux qui pensent que faire du REST c’est uniquement exposer des services HTTP occultent des caractéristiques essentielles de REST, les intérêts inhérents à ces caractéristiques mais également les difficultés. Concevoir une Architecture Orientée Ressources n’est pas facile. Mais il s’agit là d’un exercice très enrichissant.

Ce post a suscité de nombreuses réactions car plutôt difficile à comprendre pour le profane. Il a donc posté quelques jours plus tard, le 24 octobre, un autre article dans lequel il explique sa démarche afin de répondre à ces critiques. Pour résumer, il part simplement du principe que ses lecteurs ont un certain niveau de formation et de compétences. Je laisse le soin à ses autres lecteurs de s’attarder sur ce point, j’ai souhaité citer ce post pour une autre raison.

Cette raison est qu’il est intéressant de constater que Roy Fielding explique lui-même que faire du REST n’est pas facile : le premier post évoquait un ensemble de règles non intuitives et donc méconnues, et celui-ci rappelle qu’il n’y a pas de recette standard pour concevoir une Architecture Orientée Ressources et que comme d’habitude tout dépend du contexte. Et surtout, que s’il est difficile de déterminer si une architecture est réellement RESTful, il est bien plus facile de savoir si elle ne l’est pas :

“I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision. What I can do is tell them what isn’t REST or that doesn’t fit my definitions, because that is something about which I am guaranteed to know more than anyone else on this planet”

Toutefois, contrairement à Roy Fielding, je pense qu’il est important de trouver un moyen pour démocratiser ces idées, justement parce qu’elles sont méconnues et incomprises : j’espère pouvoir rédiger bientôt une sorte de checklist qui serait utilisable par les connaisseurs comme par les profanes. Le tout en essayant de faire preuve d’un peu plus d’ouverture…