Voici le premier article de nos Carnets de Vol ! Il s’agit du premier élément d’une série d’articles dont l’objectif est de présenter clairement REST, ou Representational State Transfer.

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.