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.

Qu’est-ce que HATEOAS ?

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).

HATEOAS et REST : le principe de l’hypermédia

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.

IvHMM0huDZk.jpg Pour afficher cette vidéo, des cookies de tiers sont nécessaires. Vous pouvez consulter et modifier vos paramètres de cookies ici.

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.

Conseil

Pour plus d’informations sur REST, consultez notre article sur le sujet.

HATEOAS en utilisant l’exemple d’une boutique en ligne

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 :

<a href="URI">Link-Text</a>

Les médias liés : textes, graphiques, audio et vidéo, sont appelés hypermédia. Les applications Web sont principalement des documents texte simples au format HTML qui peuvent également être considérés comme des états de ces applications. Dans le cadre de la philosophie REST, les documents individuels peuvent toujours être adressés avec une URL unique. Si vous transférez le concept à une boutique en ligne ordinaire, les résultats suivants se traduiront par :

Le document décrivant l’état « panier » a un URI assigné en permanence, par exemple : 'https://exemple.org/panier'. Dans le même style, il existe également des URI pour les articles individuels qui peuvent être placés dans le panier, tels que 'https://exemple.org/article/1', 'https://exemple.org/article/2', etc. L’état possible est le compte client, auquel on peut accéder directement à partir du panier et qui peut avoir l’URI suivant : 'https://exemple.org/acheteur/1'. Chaque document individuel contient également des liens ou des hyperliens vers des actions que l’utilisateur pourrait effectuer ensuite.

Pour conserver le scénario actuel, cela signifie que le document de panier contient également des références croisées à l’article et aux URI du client. Celles-ci pourraient à leur tour contenir d’autres liens vers des fabricants ou des documents contractuels. Grâce à une requête GET, le client se déplace ensuite dans la boutique ou, dans ce cas, dans le panier, grâce aux différents liens hypertexte, comme l’illustre l’image simplifiée suivante :

HATEOAS exemple : boutique en ligne
Représentation schématique de l’implémentation de HATEOAS dans une boutique en ligne

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.

Les applications HATEOAS REST : exemple de la communication serveur-client

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 :

GET https://exemple.org/panier HTTP/1.1
Host: https://exemple.org
Accept: application/xml

La réponse du serveur pourrait ressembler à ceci :

Content-Type: application/xml
Content-Length: 256
<?xml version="1.0"?>
<panier>
    <panier_number>1</panier_number>
    <link rel="compte" href="https://exemple.org/customer/1"/>
    <link rel="article1" href="https://exemple.org/article/1"/>
    <link rel="article2" href="https://exemple.org/article/2"/>
</panier>
Cet article vous a-t-il été utile ?