Dans un souci d’être toujours plus compétitifs tout en répondant à vos attentes, vous pourrez constater que nous vous avons réservé des promotions sur certaines formations.

N’hésitez pas à nous contacter pour tout complément : sur votre demande, nous pouvons mettre sur pied tous types de formations.

Nous animons nos formations dans des contextes inter-entreprises et intra-entreprises et notre catalogue est réparti selon nos thèmes clés :

• Thème « Applications Riches» 
  • Rich Internet Applications (RIA)
  • Rich Desktop Applications (RDA)
  • Rich Mobile Applications (RMA)
• Thème « Architectures Applicatives» 
  • Développement Java/JEE
  • Développement C#/.NET
  • Sujets transverses
• Thème « Méthodes et Outils» 
  • Conception et modélisation
  • Méthodologies

Voici les dates des premières formations planifiées :

• 21 septembre 2009 : Développement iPhone et iPod Touch [R-IPH]
  • Formation animée par François GOLDGEWICHT, Consultant Senior et Directeur Technique d’Aeon Consulting, qui a développé et distribué plusieurs applications iPhone à succès
  • Un iPod Touch offert à chaque participant à l’issue de cette formation !
• 05 octobre 2009 : Développement Spring 3.0 [A-SPR]
• 19 octobre 2009 : Introduction au développement iPhone et iPod Touch [R-IPHI]
• 09 novembre 2009 : Introduction à REST [A-RSTI]
• 16 novembre 2009 : Panorama des styles et technologies RIA [R-PAN]
• 23 novembre 2009 : Introduction au Cloud Computing [A-CLDI]
• 30 novembre 2009 : Développement iPhone et iPod Touch [R-IPH]
  • Voir session du 21 septembre 2009
• 07 décembre 2009 : Développement Spring 3.0 [A-SPR]
• 04 janvier 2010 : Introduction au développement iPhone et iPod Touch [R-IPHI]
• 11 janvier 2010 : Introduction à REST [A-RSTI]
• 18 janvier 2010 : Panorama des styles et technologies RIA [R-PAN]
• 25 janvier 2010 : Introduction au Cloud Computing [A-CLDI]

Vous pouvez découvrir la description de nos formations, notre catalogue ainsi que les modalités d’inscription sur la page dédiée : Formations.

N’hésitez pas à nous contacter pour tout complément : sur votre demande, nous pouvons mettre sur pied tous types de formations.

Notion d’Adressabilité

Il s’agit d’une notion assez simple à appréhender. On peut d’abord définir l’Adressabilité de la manière suivante, comme Leonard Richardson et Sam Ruby dans leur excellent ouvrage RESTful Web Services : une application adressable est une application qui présente ses informations « intéressantes»  en tant que Ressources. En effet, alors, chacune de ces informations possède un URI, et cet URI la rend accessible.

On ne le rappellera jamais assez : peut être une ressource tout objet assez important pour être référencé en tant que tel. La capacité d’une Ressource à être référencée la rend « adressable» . Dans quel but ? Le document URIs, Addressability, and the use of HTTP GET and POST du Technical Architecture Group du W3C nous donne une réponse typiquement dans la lignée de la philosophie RESTienne :

« we can refer to things [...], access them, describe them, and share them. Providing a URI for a resource affords many advantages, including: linking, bookmarking, caching» 

A force d’en profiter quotidiennement dans le Web qu’on connaît – et parfois, de manière transparente, ces apports peuvent avoir l’air banal mais ils sont fondamentaux. Plus généralement, référencer des Ressources par de simples identifiants permet de s’affranchir des différences entre langages et plateformes. C’est là que le « U»  de « URI» , pour « Uniform»  , prend tout son sens :

« Great multiplicative power of reuse derives from the fact that all languages use URIs as identifiers: This allows things written in one language to refer to things defined in another language. [...] In this finding, the term ‘URI addressability’ means that a URI alone is sufficient for an agent to carry out a particular type of interaction.» 

Il devient en effet facile de créer des liens vers ces identifiants afin d’opérer des actions sur les Ressources référencées. Cette simplicité est l’un des facteurs clés du succès du Web que nous connaissons.

Notion d’URI

On peut définir simplement un URI comme étant à la fois le nom et l’adresse d’une Ressource. En effet, comme nous l’indique Roy Fielding dans sa thèse où il définit REST :

« Resource identifier [allows] to identify the particular resource involved in an interaction between components» 

En effet, rappelons la définition de Ressource que nous avons donnée dans le post précédent : peut être une ressource tout objet assez important pour être référencé en tant que tel. Dans cette optique, l’URI d’une Ressource est justement le moyen de référencer cette Ressource.

Un URI identifie une Ressource donc n’est rattaché qu’à cette seule Ressource. Mais une Ressource peut être rattachée à plusieurs URI. En pratique, on essaie tout de même de limiter le nombre d’URI rattachés à une Ressource afin de ne pas réduire leur valeur.

Et voilà, à ce stade, nous pourrions presque terminer ce post. Mais nous constatons souvent des confusions autour de cette notion qui est bien plus complexe qu’elle ne paraît, en particulier dans ce qui caractérise la relation entre un URI et sa Ressource.

Persistance des URI

Voici un premier sujet de confusions. La recommandation « Architecture of the World Wide Web, Volume One» du W3C, co-rédigée par Roy Fielding, nous explique l’importance de la notion de persistance des URI, dont elle donne une définition :

« the term URI persistence is used to describe the desirable property that, once associated with a resource, a URI should continue indefinitely to refer to that resource» 

Cette règle est simple : les URI doivent être affectés durablement.

Ce principe est cependant parfois mal compris. Ainsi, on peut parfois lire ou entendre qu’il y a un cas intéressant de non respect de cette règle :

• l’URI http://www.aeon-consulting.fr/an-application/1.0 pointe vers la Ressource « Version 1.0 de l’application ‘an application’»  de manière définitive
• l’URI http://www.aeon-consulting.fr/an-application/last pointe vers la Ressource « Dernière version de l’application ‘an application’» , qui peut correspondre de manière temporaire à la Ressource précédente (tant que la version 1.0 de l’application est la version la plus récente).

Il s’agirait là d’une utilisation pertinente d’un URI non persistant. Cette vision est erronée car la Ressource « Dernière version de l’application ‘an application’»  n’est pas la même que la Ressource « Version 1.0 de l’application ‘an application’»  : il s’agit de deux objets distincts. La confusion vient simplement du fait que temporairement, ces deux URI permettent de récupérer deux représentations identiques.

Notons que si nécessaire, le protocole HTTP fournit les mécanismes de redirection qui permettent d’indiquer aux agents que l’URI d’une Ressource a changé (via les codes 3XX des réponses HTTP).

Signification des URI

Signification des URI et état des Ressources

Utilisation d’URI significatifs, ou transparents

Dans le Web que nous utilisons tous les jours, on trouve fréquemment des URI significatifs : en effet, la connaissance de l’URI d’une Ressource parente nous permet (presque !) de retrouver les URI des Ressources filles qui nous intéressent. Il est donc naturel de suggérer pour nos Ressources des URI structurés, significatifs et descriptifs, voire même prévisibles.

Voici à titre d’exemple l’URI d’un article de ce blog, très significatif pusqu’il porte la date et le titre de l’article :

http://…/blog/2009/07/08/comprendre-rest-partie-1-ressource/

Utilisation d’URI non significatifs, ou opaques

La même recommandation du W3C nous indique qu’un URI n’est pas nécessairement significatif :

« The choice of syntax for global identifiers is somewhat arbitrary, it is their global scope that is important» 

Il s’agit du principe d’opacité des URI : un URI est un identifiant, il sert uniquement à identifier une Ressource pour permettre de la référencer. Il ne doit pas servir à donner des informations sur l’état de la Ressource, ce sont les Représentations de la Ressource qui jouent ce rôle, comme nous l’indique ce même document :

« It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations, not identifiers» 

Nous reviendrons ultérieurement sur la notion de Représentation. Voici à titre d’exemple une version opaque de l’URI de notre article de blog :

http://…/blog/126/

Cet URI est opaque car il porte un identifiant technique et non plus la date et le titre de l’article (qui sont des informations sur l’état de la Ressource article, qui peuvent en outre évoluer et donc violer la règle de persistance énoncée précédemment).

Un peu de recul…

Mais alors, que choisir entre URI significatifs et URI opaques ? En fait REST n’interdit pas l’utilisation d’URI significatifs, la contrainte est uniquement dans le fait qu’une Ressource doit avoir un identifiant. Le choix entre opacité et transparence des URI est et restera un sujet subjectif. Bien souvent, c’est la sémantique que l’on souhaite mettre en place dans la construction des URI qui permettra de faire un choix.

Signification des URI et format de Représentation des Ressources

Un URI ne doit pas servir à donner des informations sur le format de représentation de la Ressource :

« In general, one cannot determine the type of a resource representation by inspecting a URI for that resource. For example, the ‘.html’ at the end of ‘http://example.com/page.html’ provides no guarantee that representations of the identified resource will be served with the Internet media type ‘text/html’. The publisher is free to allocate identifiers and define how they are served» 

En effet, ce rôle est notamment assuré par la Négociation de contenu, qui fera l’objet d’un post ultérieur. Cette règle très importante n’est pas intuitive car elle n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Signification des URI et actions opérées sur les Ressources

De la même manière, un URI ne doit pas servir à donner des informations sur les actions opérées sur les Ressources : c’est la méthode HTTP qui joue ce rôle, comme nous le verrons dans un post ultérieur dédié à la notion d’Interface uniforme. Là encore, cette règle très importante n’est pas intuitive car elle non plus n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Syntaxe des URI

Sur ce point, REST n’impose rien explicitement. Cependant, les règles suivantes de syntaxe sont souvent mises en œuvre :

• utilisation du caractère ‘/’ pour aller du niveau le plus général au niveau le plus spécifique : /Dossier1/Fichier2 par exemple
• utilisation du caractère ‘,’ pour indiquer des éléments ordonnés : /coordonnees/43.55197,1.489613 par exemple
• utilisation du caractère ‘;’ pour indiquer des éléments non ordonnés : /couleurs/bleu;vert par exemple
• utilisation des caractères ‘?’ et ‘&’ pour indiquer des paramètres, souvent pour des Ressources générées dynamiquement : /search?q=aeon&hl=fr

Ajoutons que la limitation de la taille des URI à 256 caractères est loin derrière nous : les serveurs ont aujourd’hui des limitations de quelques milliers de caractères.

Mais au fait, quel est le lien entre URI et URL ?

Le terme URI fait penser à un terme bien connu dans le Web que nous utilisons tous les jours : URL (Uniform Resource Locator).

Quelle est donc la différence entre ces deux termes très proches, souvent amalgamés ? La RFC 2396, qui définit la syntaxe des URI, nous donne une réponse explicite :

« A URI can be further classified as a locator, a name, or both. The term « Uniform Resource Locator»  (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network « location» ), rather than identifying the resource by name or by some other attribute(s) of that resource» 

Les puristes REST auront peut-être repéré que dans cet article, on a davantage évoqué « REST appliqué à HTTP»  que « REST tout court» . Il s’agit d’un choix volontaire : d’une part, rappelons que le Web est une application des principes REST (et non l’inverse). HTTP 1.1 a été conçu afin de permettre cette application. D’autre part, cela permet de donner un aspect pragmatique à ces explications, dont le but est de clarifier les caractéristiques de REST.

Depuis son apparition il y a 9 ans, et plus particulièrement ces toutes dernières années, REST en intéresse plus d’un : beaucoup de monde en parle et déclare « en faire» .  Mais en pratique, beaucoup d’interrogations demeurent sur ce qu’est réellement REST et sur ce que ce n’est pas. Plutôt que de s’appuyer comme d’habitude sur un unique article qui deviendrait vite volumineux et difficile à appréhender, j’ai choisi de vous présenter REST en une dizaine de notions que nous allons aborder de manière incrémentale et pragmatique. Ces articles n’ont pas vocation à être exhaustifs mais simplement à mettre en lumière de manière structurée les caractéristiques essentielles de REST en essayant de faire disparaître la plupart des incompréhensions.

Ce premier article est consacré à la notion de « Ressource» .

Notion de Ressource

Une Ressource ? Mais tout le monde sait ce que c’est !

Peut-être serez-vous surpris de découvrir que le premier article de cette série concerne la notion de Ressource. Après tout, il s’agit d’un mot banal, bien ancré dans le jargon quotidien de l’informaticien. Et bien justement, ce mot est tellement employé qu’il est devenu difficile de savoir sa définition précise, dans le cadre de REST notamment. Lors de mes missions, on me demande parfois cette définition, ce qui m’amène à chaque fois à commencer ma réponse par le sondage suivant : « Comment définiriez-vous une Ressource ?» 

Et cela ne rate jamais, les réponses sont divisées en deux groupes :

• certains pensent qu’une Ressource correspond à un objet métier manipulé par l’application : par exemple, des contrats, des clients, etc. Généralement, l’idée associée est qu’un service REST correspond à un simple service de type CRUD sur ces objets métier (je ne m’attarde pas sur ce point précis qui fera l’objet d’un prochain article)
• d’autres pensent à une Ressource comme quelque chose de flou, tournant autour de tout et de rien : naturellement, cette définition peu précise contribue largement aux incompréhensions autour de REST. Cependant, nous allons le voir, elle n’est paradoxalement pas si loin de la vérité…

Commençons donc par la base : qu’est-ce qu’une Ressource (dans le contexte REST) ?

Définition d’une Ressource

Dans sa fameuse thèse, Roy Fielding nous donne une définition large et ouverte :

« Any information that can be named can be a resource: a document or image, a temporal service (e.g. « today’s weather in Los Angeles» ), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource« 

Autrement dit : peut être une ressource tout objet assez important pour être référencé en tant que tel.

La recommandation « Architecture of the World Wide Web, Volume One»  du W3C, co-rédigée par Roy Fielding, est très explicite sur l’ouverture volontaire de cette définition :

« We do not limit the scope of what might be a resource» 

Rappelons au passage que le Web est une application des principes REST (et non l’inverse). Il est donc essentiel de bien comprendre son architecture.

Et voilà, c’est aussi simple que cela. Vous l’aurez peut-être deviné, le prochain article de cette série sera consacré à la notion d’URI.