HATEOAS : que signifie cet acronyme ?

Representational State Transfer, mieux connu sous l’acronyme REST, est le plus populaire des paradigmes de programmation pour les développeurs aujourd’hui. Ce style d’architecture que Roy Fielding a inventé dans sa thèse de doctorat datant de 2000, sert principalement à adapter au mieux les applications Web aux exigences du Web moderne. REST ayant acquis une popularité et une importance notable au cours des dernières années, de nombreux opérateurs de projets Web tentent de plus en plus d’implémenter ce concept au mieux de leurs capacités. Cependant, les résultats de ces efforts ne sont pas souvent « RESTful » ou «conformes à « REST», car certains principes et propriétés (tels que HATEOAS) n’ont pas été correctement mis en œuvre.

HATEOAS est l’acronyme pour « Hypermedia as the Engine of Application State ». Ce terme, a été introduit par Fielding dans le cadre de sa définition de REST, pour décrire l’une des propriétés clefs de REST : le style d’architecture étant censé fournir une interface universelle, HATEOAS exige que le client REST se déplace uniquement dans l’application Web en suivant les URI (Uniform Resource Identifiers) au format hypermédia. Si ce principe est mis en œuvre, le client ne nécessite aucune information supplémentaire, hormis une compréhension de base de l’hypermédia pour pouvoir interagir avec l’application ou le serveur.

Les URI individuels sont fournis ...

• Sous la forme d’attributs href et src pour des documents HTML ou des snippets
• En utilisant JSON ou des attributs/éléments XML qui sont automatiquement reconnus par les clients respectifs

En implémentant le principe HATEOAS, l’interface d’un service REST peut être adaptée à tout moment. C’est un avantage important de cette architecture par rapport à d’autres structures d’application, par exemple celles basées sur SOAP (Simple Object Access Protocol).

Afin de classer HATEOAS et sa signification pour les applications REST, vous devez jeter un œil à la construction globale. Dans son concept, Fielding décrit un total de cinq principes de base qui doivent être remplis afin de rendre un service conforme REST.

Dans tous les cas, il doit y avoir une structure client-serveur qui permette également une communication sans état entre le serveur et les clients (c’est-à-dire que les demandes sont traitées sans se référer aux requêtes précédentes). En outre, le service doit avoir une structure multicouche et tirer parti de la mise en cache HTTP pour que le client accédant puisse utiliser le service le plus simplement possible. Enfin, la mise en place d’une interface uniforme pour les tâches obligatoires, qui a déjà été mentionnée, fait également partie du paquet.

Fielding spécifie quatre propriétés pour la connexion entre le serveur et le client :

• Identifiable unique de toutes les ressources : toutes les ressources doivent être identifiées par un URI (Unique Resource Identifier).
• Interaction possible avec des ressources via des représentations : si un client demande une ressource, le serveur délivre une forme de représentation / format d’affichage appropriée (par exemple HTML, JSON ou XML) afin que le client puisse modifier ou supprimer la ressource d’origine.
• Messages auto-descriptifs : chaque message échangé entre le serveur et le client doit contenir toutes les informations nécessaires à sa compréhension.
• Hypermédia comme moteur d’état d’application (HATEOAS) : après tout, le principe HATEOAS est également un composant obligatoire d’une API REST. La structure hypermédia simplifie l’accès à l’application pour les clients - aucune connaissance supplémentaire de l’interface n’est requise pour l’accès et la navigation.

HATEOAS est une des fonctionnalités élémentaires des API REST, indispensable pour tout service REST.

Afin de rendre le concept HATEOAS un peu plus tangible, la mise en œuvre du concept sera illustrée en utilisant comme exemple une boutique en ligne. Comme c’est généralement le cas pour les applications Web, HATEOAS est implémenté en plaçant des hyperliens. Ces références croisées entre deux documents ou des références croisées à une autre position dans le même document sont marquées dans le code HTML comme ceci :

Dans le cas d’un service REST, dans lequel le principe HATEOAS a été respecté comme requis par Fielding, l’utilisateur doit uniquement connaître l’URI de démarrage pour pouvoir profiter de l’offre comme prévu par le développeur.

Sur la base de la structure de la boutique en ligne mentionnée ci-dessus, la communication possible entre le client et le serveur peut également être expliquée. L’application client fait la demande suivante afin d’obtenir une représentation XML de l’état du panier :

La réponse du serveur pourrait ressembler à ceci :