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 ...
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.
Afin de protéger votre vie privée, la vidéo ne se chargera qu'après votre clic.
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 :
HATEOAS est une des fonctionnalités élémentaires des API REST, indispensable pour tout service REST.
Pour plus d’informations sur REST, consultez notre article sur le sujet.
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 :
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 :
GET https://exemple.org/panier HTTP/1.1
Host: https://exemple.org
Accept: application/xmlLa 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>
L’utilisation parallèle de différents systèmes a connu une recrudescence ces dernières années, et cela est notamment lié à la multiplication des appareils mobiles. Pour réagir à cette tendance, de nombreux services Web ont été développés, qui permettent l’interopérabilité des transferts de données. Le Representational State Transfer (REST) est un paradigme qui a été formulé en 2000 dont la...
Les bases de données NoSQL sont devenues depuis longtemps une alternative populaire aux bases de données relationnelles classiques comme MySQL. La structure de mémorisation non flexible des modèles traditionnels y est adaptable et permet leur sécurisation. Ainsi, la base de données peut par exemple être distribuée sur plusieurs serveurs pour garantir une plus grande disponibilité des applications...
Les architectures microservices ont établi une façon relativement nouvelle de structurer des applications complexes. Au lieu de vous appuyer sur une structure monolithique qui consiste à réaliser des tâches dans une seule et même application, vous développez un programme à partir de plusieurs petits services autonomes. Les microservices sont également associés à une restructuration des processus...
Les applications Web ont besoin d’interfaces pour pouvoir échanger des données. Si vous gérez un projet Web, et que vous souhaitez accorder à d’autres programmes un accès à certaines de vos données, une API () est indispensable. De nombreux développeurs ont alors recours à des concepts bien établis comme REST ou SOAP. Il existe cependant d’autres options, comme par exemple GraphQL.
La Continuous Delivery permet aux développeurs d’automatiser le développement, le contrôle qualité, les tests, la production et la livraison. Le client reçoit un logiciel à un stade plus précoce alors que le programme est encore en cours. Le pipeline nécessaire pour y parvenir est divisé en phases de test. Quelles sont-elles, quels sont les avantages de cette méthode et quels sont les outils...
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
