REST est une définition de style d'architecture appliquée aux applications en réseau. Il s'agit d'une série de contraintes appliquées à la mise en œuvre des composants du réseau, permettant une sémantique d'interface uniforme, plutôt que des mises en œuvre et une syntaxe spécifiques à l'application.
REST en tant qu'architecture de réseau a été documenté pour la première fois par Roy Fielding dans sa thèse de doctorat intitulée Architectural Styles and the Design of Network-based Software Architectures (Styles architecturaux et conception d'architectures logicielles basées sur le réseau), publiée en 2000. REST permet aux clients d'interagir avec les données stockées sur un serveur, sans avoir aucune connaissance préalable du serveur ou de ce qui s'y trouve.
REST est l'acronyme de Representational State Transfer (transfert d'état représentationnel). Les puristes de l'acronyme l'écrivent souvent ReST, car le E de REST ne signifie rien en réalité. Il s'agit simplement de la deuxième lettre du mot "Representational". Cela permet d'éviter les controverses sur la façon de le prononcer, comme celle qui a touché le GIF ces dernières années. Le E étant inclus, il n'y a pas de confusion lorsque l'on prononce l'acronyme plus précis de RST comme "poignet" ou même comme R-S-T.
Les alertes personnalisées et la visualisation des données vous permettent d'identifier et de prévenir rapidement les problèmes de santé et de performance du réseau.
Il n'existe pas de définition ou de norme spécifique de ce qu'est REST. En tant qu'architecture, REST définit la manière dont les différents composants sont reliés par des connecteurs et dont les données sont échangées par le biais d'interfaces. REST est une série de contraintes ou d'exigences qui, lorsqu'elles sont respectées, créent une implémentation du style architectural REST.
L'architecture REST n'encourage pas la création de méthodes supplémentaires spécifiques à une situation donnée. Par exemple, une architecture REST utilise la méthode GET pour récupérer des données en toutes circonstances. Le seul changement pour les différents types de données serait des paramètres différents. Il en va autrement de la création d'une nouvelle méthode pour obtenir des informations sur un utilisateur (getUser), et d'une autre méthode encore pour obtenir des informations sur les prix (getPricing), et ainsi de suite.
L'interface utilisateur du client est séparée et indépendante du stockage des données sur le serveur. Cela permet de mettre en œuvre et de modifier le client indépendamment de ce qui se passe ou ne se passe pas sur le serveur. De même, les données d'un serveur peuvent être utilisées et modifiées indépendamment de la manière dont le client y accède. Une telle conception permet aux systèmes client et serveur d'évoluer à leur propre rythme, indépendamment l'un de l'autre.
Aucune donnée de session ne doit être stockée sur le serveur entre les requêtes du client. En d'autres termes, chaque transaction doit permettre de comprendre complètement la demande sans qu'il soit nécessaire d'accéder à un contexte ou à des données supplémentaires stockées sur le serveur. Toutes les données de session doivent résider exclusivement sur le client.
Cette contrainte permet un équilibrage de charge simplifié ou une tolérance aux pannes. Un serveur différent peut répondre à chaque demande d'un client et renvoyer les mêmes données que le serveur d'origine, à condition que les deux serveurs disposent des mêmes données d'origine. Il n'est pas nécessaire de transmettre des données spécifiques à une session entre ces serveurs d'équilibrage de charge. Les sessions qui ne sont pas sans état peuvent donner lieu à des réponses différentes si la demande est traitée par un autre serveur, car seul le serveur précédent dispose des données spécifiques à cette session avec le client.
Dans chaque Exchange, les données doivent être marquées soit comme des données pouvant être mises en cache, soit comme des données ne pouvant pas être mises en cache. Les données pouvant être mises en cache peuvent être stockées et réutilisées par le client. Aucune donnée n'est mise en cache sur le serveur, car cela violerait la contrainte d'absence d'état. La possibilité de mettre des données en cache réduit l'augmentation de la bande passante nécessaire au maintien d'une session client-serveur sans état.
Pour parvenir à une interopérabilité totale, l'interface est découplée du type de données, à condition que toutes les interactions fonctionnent de la même manière. Quatre sous-contraintes garantissent l'uniformité des interfaces : l'identification des ressources, la manipulation des ressources par le biais de représentations, les messages auto-descriptifs et les hypermédias en tant que moteur de l'état de l'application (HATEOAS).
Toute information qui peut être nommée est une ressource. Une ressource peut être n'importe quelle forme de données. Un identifiant de ressource est un moyen de se référer à une ressource spécifique à un moment donné. Ces ressources peuvent être mises à jour sur le serveur sans que le client n'ait besoin d'en avoir connaissance à l'avance, car chaque demande est entièrement décrite et reçoit une réponse.
Une représentation est l'état actuel d'une ressource, ainsi que les métadonnées qui l'accompagnent et qui permettent de comprendre la représentation. Le format de données d'une représentation définit son type de média. Ainsi, un client peut demander une ressource, telle qu'une image, à un serveur en utilisant l'identifiant de cette ressource (probablement un URI), et une représentation de cette image composée des octets qui constituent l'image, ainsi que les métadonnées qui définissent le format de données comme un type de média JPG, sera renvoyée au client, qui pourra alors afficher l'image à l'utilisateur.
Chaque message envoyé par le client au serveur doit contenir toutes les informations nécessaires à son traitement. Dans le cas de la sécurité et de l'authentification, le jeton de sécurité doit être échangé dans chaque message.
Les cookies sont très populaires sur l'internet. Le fait de vérifier le cookie par rapport à toutes les données de chaque message serait un exemple de message non auto-descriptif, et donc techniquement non RESTful.
Définition de l'hypermédia
L'hypermédia est similaire au concept d'hypertexte, ou de liens hypertextes, sauf qu'il englobe toutes les formes de médias et pas seulement le texte ou les liens. Il s'agit d'une manière non linéaire de fournir des informations ou des données, généralement en suivant un lien ou un autre marqueur dans une ressource publiée telle qu'une page web. Les hypermédias peuvent être des textes, des graphiques, des vidéos ou d'autres formes de données.
Dans le cadre de HATEOAS, un client interagit via un réseau au moyen d'hypermédias
Le client interagit avec un serveur en utilisant uniquement l'hypermédia. Ce même hypermédia est fourni dynamiquement par le serveur en réponse à une requête RESTful. Par conséquent, aucune connaissance préalable des données sur un serveur, de leur structure, ni de la façon dont ces données sont stockées n'est nécessaire. Au lieu de cela, il suffit d'utiliser une structure et des méthodes hypermédia bien définies.
Dans un système de couches hiérarchiques, aucun composant ne peut interagir avec ou voir des données ou une interface en dehors de sa propre couche immédiate. Par conséquent, le client n'a pas besoin de savoir comment se connecter à un serveur supplémentaire, à un proxy, à un pare-feu, à un routeur ou à un point d'extrémité, ni même s'il est nécessaire de le faire. Au contraire, tout intermédiaire continuera à se connecter aux serveurs suivants conformément aux contraintes REST, et la réponse résultante à toute requête renvoyée au client via les intermédiaires sera également conforme à REST. Les changements ou perturbations des systèmes intermédiaires sont donc invisibles pour le client, ce qui permet à ces systèmes intermédiaires d'assurer l'équilibrage de charge, la sécurité ou d'autres fonctions.
Bien qu'ils soient techniquement qualifiés d'optionnels, les clients d'une architecture REST devraient pouvoir télécharger et exécuter des scripts. Cela permet d'étendre des fonctionnalités et des systèmes plus complexes, tout en assurant la même communication de type REST entre le client et le serveur. Comme pour les requêtes et les réponses de base, l'instruction complète pour l'exécution du code scripté doit être indépendante et ne pas nécessiter d'implémentation préalable sur le client.
Par exemple, un client web peut exécuter du JavaScript qu'il reçoit du serveur. Bien que le code réside sur le serveur, il n'y est pas exécuté. Au contraire, le code lui-même est envoyé au client dans le cadre de la demande, et ce code est exécuté par le client conformément à son implémentation. C'est la raison pour laquelle il est essentiel que les clients web appliquent correctement les normes, faute de quoi le même code provenant du serveur peut être exécuté avec des résultats différents sur des clients différents.
Les notifications en temps réel sont synonymes de dépannage plus rapide, ce qui vous permet d'agir avant que des problèmes plus graves ne surviennent.
Les composants d'un système REST communiquent via une représentation d'une ressource dans l'un des nombreux formats standardisés convenus, tels que les formats graphiques, les formats de documents et divers formats web. Encore une fois, pour être un véritable système REST, chaque transaction doit contenir la capacité de récupérer et d'interpréter la ressource souhaitée.
Une ressource est tout ce qui peut être nommé. Il s'agit de la ressource stockée sur le serveur et demandée par le client. Une ressource peut être un fichier statique, un document, une base de données, une image ou tout autre format pouvant être demandé.
Bien qu'il s'agisse aujourd'hui d'un concept courant, l'idée originale d'une ressource en tant qu'élément générique, modifiable et ponctuel était une caractéristique clé de REST et du web en général. Une ressource est une donnée nommable sur un serveur. Ces données peuvent être remplacées non seulement par une version plus récente des mêmes données, mais aussi par un type de données entièrement différent. Les données d'un serveur peuvent ainsi être mises à jour à tout moment sans qu'aucun client n'ait besoin de le savoir à l'avance, ce qui constitue une caractéristique essentielle de l'interopérabilité et de la disponibilité.
L'identifiant de la ressource est l'emplacement spécifique de la ressource demandée. Dans le cas d'un système basé sur HTTP, l'identificateur de ressource est l'URL ou l'URI. L'identificateur de ressource spécifie une seule ressource. Un identifiant de ressource unique peut faire référence à différentes données ou ressources à différents moments. Dans un système conforme à REST, le client n'a pas besoin de savoir à l'avance quel type de ressource l'identificateur de ressource demande. La réponse comprendra des métadonnées qui décrivent comment interpréter les données reçues.
Par exemple, même si une demande URL indique /server/index.html, si la ressource à cette adresse renvoie une représentation sous la forme d'un fichier image, avec les métadonnées correspondantes, le fichier image sera toujours correctement affiché, indépendamment de ce qu'a dit l'identifiant de la ressource.
Il s'agit des données envoyées au client. Comme indiqué ci-dessus, la représentation doit correspondre à l'un des formats de données normalisés. Les données ne sont pas traitées sur le serveur, mais interprétées par le client. Par exemple, un client qui demande un document HTML ne reçoit pas un graphique à afficher sur le superviseur, mais plutôt un ensemble de code HTML qui est ensuite interprété et affiché sur le client. Les fichiers graphiques tels que les images JPEG et GIF constituent d'autres exemples de représentation.
Les métadonnées de représentation fournissent au système des informations sur la représentation. Comme la plupart des métadonnées, les métadonnées de représentation ne font généralement pas partie de ce qui est affiché à l'utilisateur final. Les métadonnées de représentation peuvent inclure le type de média, une date de création et de modification, et un numéro de version.
Les métadonnées de ressource sont des informations supplémentaires fournies au système sur la ressource qui existe sur le serveur plutôt que sur la représentation affichée sur le client. Les métadonnées de ressource comprennent par exemple les liens source, les alternatives et les informations sur la ressource. Par exemple, les métadonnées de ressources peuvent inclure un texte de remplacement à afficher au cas où une représentation d'image ne pourrait pas être affichée pour une raison quelconque (par exemple, le texte d'image ALT en HTML).
Les données de contrôle concernent principalement la validité de la ressource et de sa représentation sur le client. Les données de contrôle indiquent si les données peuvent être mises en cache ou non, ainsi que le délai d'expiration absolu, ou fournissent une limite à la durée d'utilisation des données. Les données de contrôle peuvent également inclure une somme de contrôle ou d'autres moyens de garantir l'intégrité.
Dans son ensemble, l'architecture REST crée un cadre hautement évolutif, totalement transparent et réutilisable, dans lequel les clients sont découplés de l'implantation des services sur les serveurs. Elle est indépendante de la plate-forme, tant pour le client que pour le serveur. Il est indépendant du langage et de la structure. Peu importe que les données existent dans une base de données, qu'elles soient récupérées par un processus de serveur Java et envoyées à un programme local - tel qu'un navigateur - codé dans l'une des nombreuses versions du langage C.
Sur le web moderne, REST est mis en œuvre à l'aide d'un vocabulaire standard commun entre le client et le serveur, connu sous le nom de protocole de transfert hypertexte, ou HTTP. Cependant, toute implémentation qui se conforme à tous les principes de l'architecture REST est considérée comme une implémentation RESTful. HTTP n'est pas la seule possibilité.
Bien que HTTP et REST ne soient pas la même chose, HTTP dans sa forme originale est une implémentation de REST. Cela n'est pas surprenant puisque Roy Fielding travaillait sur le protocole HTTP 1.1, tout en développant l'architecture REST.
Chaque ressource est identifiée par un identifiant de ressource uniforme (URI). En règle générale, cet identifiant est mis en œuvre sous la forme d'une URL dans un navigateur web. Un URI identifie une ressource. Aucune connaissance préalable du système dans lequel la ressource réside sur le serveur n'est requise. En outre, l'URI (ou URL) est capable de spécifier la représentation d'une ressource, sans connaissance de la structure du fichier de cette ressource.
Dans HTTP, la représentation des ressources est mise en œuvre par la prise en charge de divers types de fichiers dans un navigateur HTTP. Ainsi, les métadonnées accompagnant une ressource définissent l'un des formats de fichier largement pris en charge, tels que HTML, CSS, JPG, GIF, etc.
Une implémentation REST pure de HTTP nécessite l'utilisation de quatre méthodes de base : GET, POST, PUT et DELETE. Chaque méthode doit être utilisée explicitement et mappée à l'une des actions de base RETRIEVE DATA, CREATE RESOURCE, UPDATE RESOURCE et DELETE RESOURCE.
Certaines méthodes HTTP doivent être idempotentes. L'idempotence signifie que l'exécution de la même méthode avec les mêmes paramètres doit toujours renvoyer le même résultat. Pour que cela fonctionne, la méthode en question ne peut provoquer aucune modification sur le serveur qui entraînerait le retour d'un résultat différent pour la même requête. En pratique, une requête idempotente ne doit pas modifier les données du serveur.
Utilisés pour récupérer une ressource ou des informations sur cette ressource. Bien que la plupart des implémentations de HTTP traitent les paramètres avec une requête GET pour modifier ou créer des ressources, une telle action ne serait pas conforme à une implémentation RESTful. Les requêtes GET doivent être idempotentes.
Une requête POST crée de nouvelles données sur un serveur. Par définition, une requête POST n'est PAS idempotente. À chaque exécution, une requête POST crée davantage de données.
Tout comme une requête POST, une requête PUT modifie des données existantes. Par exemple, changer le nom de famille d'un utilisateur existant. Les requêtes PUT ne sont pas intuitivement idempotentes. Bien qu'une requête PUT modifie les données, elle le fait de la même manière à chaque fois. Ainsi, l'exécution d'une requête PUT qui modifie le nom de famille d'un utilisateur produira toujours le même résultat tant que tous les paramètres sont cohérents.
Une requête DELETE supprime des données, comme son nom l'indique. Les requêtes Delete sont également idempotentes, en ce sens que l'exécution répétée d'une requête aboutira toujours au même état final, c'est-à-dire que les données en question n'existeront plus sur le serveur. Cependant, pour le client, il peut sembler y avoir une différence dans la mesure où, une fois qu'une ressource est supprimée, la demande peut recevoir un message d'erreur tel que "fichier introuvable". Cependant, la méthode est toujours considérée comme idempotente, car quelle que soit l'erreur envoyée au cours de la transaction, l'état final d'une telle requête est le même que la première fois qu'elle est demandée.
PRTG est un logiciel de supervision Network complet qui assure le suivi de l'ensemble de votre infrastructure IT.
Dans un billet publié sur son blog, aujourd'hui abandonné, Roy Fielding a évoqué les critères auxquels une API doit répondre pour être considérée comme véritablement RESTful. S'appuyant sur sa thèse précédemment publiée, ce billet décrivait les mêmes concepts d'architecture REST tels qu'ils devraient s'appliquer aux API.
Une API RESTful est donc une API qui utilise UNIQUEMENT l'architecture REST sans avoir besoin de documentation ou de méthodes supplémentaires au-delà de celles qui correspondent au modèle. Fielding a fourni les points suivants pour clarifier ce qui rend une API RESTful.
Une API RESTful ne doit pas dépendre d'un seul protocole et doit pouvoir prendre en charge tout protocole utilisant l'URI pour l'identification. Dans le cas contraire, l'identification n'est pas séparée de l'interaction.
Une API REST ne doit pas nécessiter de modifications des protocoles normalisés, en particulier l'ajout de fonctionnalités supplémentaires. Dans la mesure du possible, les solutions de contournement requises doivent être définies séparément, l'objectif étant de les supprimer une fois qu'elles ne sont plus nécessaires.
L'espace de noms d'un serveur doit être indépendant de la définition et des exigences de l'API. En d'autres termes, l'API doit fonctionner avec n'importe quel serveur compatible REST, et pas seulement avec des serveurs conformes à une spécification particulière de l'API.
