Dès le 21 septembre prochain, j’aurai ainsi le plaisir d’animer une formation complète de 5 jours sur le Développement iPhone et iPod Touch, à l’issue de laquelle un iPod Touch sera offert à chaque participant !

Nous proposons également une introduction d’une journée sur ce même sujet, pour ceux qui souhaitent simplement appréhender et comprendre cette plateforme révolutionnaire et ses enjeux.

Ce n’est pas tout ! Notre catalogue est constitué de sujets variés, rassemblés autour des thèmes “Applications Riches” (Internet, Desktop et Mobile), “Architectures Applicatives” (Java/JEE, C#/.NET) et “Méthodes et Outils” (Conception, modélisation, méthodologies).

Vous trouverez tous les détails sur notre site. Surtout n’hésitez pas à nous contacter pour tout complément : sur votre demande, nous pouvons mettre sur pied tous types de formations.

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 !

• 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

Ce premier événement toulousain s’est très bien passé : une vingtaine de participants aux profils très variés ont pu assister à la présentation de Bruno sur le sujet “2009 : technologies, langages, frameworks” et ont donc pu échanger avec nous sur tous les buzz du moment.

Avant de me plonger dans la préparation de la deuxième session, je félicite Bruno pour sa présentation et je remercie Laetitia de m’avoir aidé à organiser cet événement.

Cette présentation passera en revue les librairies, outils, concepts et technologies qui vont compter dans les mois à venir, et fera le point sur les buzz du moment. Si vous êtes curieux et intéressés par les évolutions de Java et de .NET, JavaFX, Gumbo, Silverlight, Azure et toutes les nouveautés à venir, alors courrez vous inscrire !

Vous trouverez toutes les informations nécessaires et le formulaire d’inscription sur la page dédiée.

Les “Présentations à la carte” sont des rencontres gratuites, pour échanger avec les consultants, formateurs et managers de Valtech Toulouse sur le sujet de votre choix. Le sujet présenté lors de la prochaine session du 3 Février sera simplement celui qui obtiendra le plus de voix à la clôture du vote en ligne.

Ce événement est un double plaisir pour moi puisque j’y participe à la fois en tant qu’organisateur et en tant qu’intervenant (sur les sujets autour du Web 2.0 et des Services Web).

N’attendez plus, allez voter et vous inscrire !

Vous pouvez même consulter les vidéos des présentations de 15 minutes sur la Valtech WebTV. Il vous faudra être encore un peu patient pour les vidéos des présentations de 45 minutes (dont la mienne fait partie), elles devraient progressivement arriver dès le mois de janvier.

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…

Mais les Valtech Days ne sont pas terminés ! Vous pouvez apporter vos contributions (avis, photos ou notes) sur le Wiki dédié : http://wiki.valtechdays.fr.

Dès que les vidéos des sessions seront disponibles, je posterai une news.