HATEOAS : que signifie cet acronyme ?

Re­pre­sen­ta­tio­nal State Transfer, mieux connu sous l’acronyme REST, est le plus populaire des pa­ra­digmes de pro­gram­ma­tion pour les dé­ve­lop­peurs aujourd’hui. Ce style d’ar­chi­tec­ture que Roy Fielding a inventé dans sa thèse de doctorat datant de 2000, sert prin­ci­pa­le­ment à adapter au mieux les ap­pli­ca­tions Web aux exigences du Web moderne. REST ayant acquis une po­pu­la­rité et une im­por­tance notable au cours des dernières années, de nombreux opé­ra­teurs de projets Web tentent de plus en plus d’im­plé­men­ter 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 pro­prié­tés (tels que HATEOAS) n’ont pas été cor­rec­te­ment mis en œuvre.

HATEOAS est l’acronyme pour « Hypermedia as the Engine of Appli­ca­tion State ». Ce terme, a été introduit par Fielding dans le cadre de sa dé­fi­ni­tion de REST, pour décrire l’une des pro­prié­tés clefs de REST : le style d’ar­chi­tec­ture étant censé fournir une interface uni­ver­selle, HATEOAS exige que le client REST se déplace uni­que­ment dans l’ap­pli­ca­tion Web en suivant les URI (Uniform Resource Iden­ti­fiers) au format hy­per­mé­dia. Si ce principe est mis en œuvre, le client ne nécessite aucune in­for­ma­tion sup­plé­men­taire, hormis une com­pré­hen­sion de base de l’hy­per­mé­dia pour pouvoir interagir avec l’ap­pli­ca­tion ou le serveur.

Les URI in­di­vi­duels 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 au­to­ma­ti­que­ment reconnus par les clients res­pec­tifs

En im­plé­men­tant le principe HATEOAS, l’interface d’un service REST peut être adaptée à tout moment. C’est un avantage important de cette ar­chi­tec­ture par rapport à d’autres struc­tures d’ap­pli­ca­tion, par exemple celles basées sur SOAP (Simple Object Access Protocol).

Afin de classer HATEOAS et sa sig­ni­fi­ca­tion pour les ap­pli­ca­tions REST, vous devez jeter un œil à la cons­truc­tion 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 com­mu­ni­ca­tion 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 mul­ti­couche et tirer parti de la mise en cache HTTP pour que le client accédant puisse utiliser le service le plus sim­ple­ment possible. Enfin, la mise en place d’une interface uniforme pour les tâches obli­ga­toires, qui a déjà été men­tion­née, fait également partie du paquet.

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

• Iden­ti­fiable unique de toutes les res­sources : toutes les res­sources doivent être iden­ti­fiées par un URI (Unique Resource Iden­ti­fier).
• In­te­rac­tion possible avec des res­sources via des re­pré­sen­ta­tions : si un client demande une ressource, le serveur délivre une forme de re­pré­sen­ta­tion / format d’affichage ap­pro­priée (par exemple HTML, JSON ou XML) afin que le client puisse modifier ou supprimer la ressource d’origine.
• Messages auto-des­crip­tifs : chaque message échangé entre le serveur et le client doit contenir toutes les in­for­ma­tions né­ces­saires à sa com­pré­hen­sion.
• Hy­per­mé­dia comme moteur d’état d’ap­pli­ca­tion (HATEOAS) : après tout, le principe HATEOAS est également un composant obli­ga­toire d’une API REST. La structure hy­per­mé­dia simplifie l’accès à l’ap­pli­ca­tion pour les clients - aucune con­nais­sance sup­plé­men­taire de l’interface n’est requise pour l’accès et la na­vi­ga­tion.

HATEOAS est une des fonc­tion­na­li­tés élé­men­taires des API REST, in­dis­pen­sable 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é­ra­le­ment le cas pour les ap­pli­ca­tions Web, HATEOAS est im­plé­menté en plaçant des hy­per­liens. 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’uti­li­sa­teur doit uni­que­ment connaître l’URI de démarrage pour pouvoir profiter de l’offre comme prévu par le dé­ve­lop­peur.

Sur la base de la structure de la boutique en ligne men­tion­née ci-dessus, la com­mu­ni­ca­tion possible entre le client et le serveur peut également être expliquée. L’ap­pli­ca­tion client fait la demande suivante afin d’obtenir une re­pré­sen­ta­tion XML de l’état du panier :

La réponse du serveur pourrait res­sem­bler à ceci :