Que signifie État de représentation dans REST?
J'ai lu partout sur le net pour avoir la signification exacte de deux mots:
ÉTAT DE REPRÉSENTATION
J'ai un doute. Je comprends mal ces termes. je veux clarifier la compréhension avec quelqu'un comment a une bonne idée à ce sujet.
Ma compréhension est que, il y a une ressource située dans le serveur. SO Rest signifie que, le transfert d'un état de représentation de cette ressource à un client.
si le serveur a une ressource x, alors si nous pouvons créer l'état représentatif y de la ressource x, et le transférer sur le Web, c'est ce que REST signifie, est-ce correct ou quelle est sa signification correcte quelqu'un pourrait-il m'expliquer cela.
Le transfert d'état représentatif fait référence au transfert de "représentations". Vous utilisez une "représentation" d'une ressource pour transférer l'état de ressource qui vit sur le serveur dans l'état d'application sur le client.
Bien que REST est sans état, il a un transfert d'état dans son nom. C'est un peu déroutant pour tout le monde.
Apatride
Lorsque vous ouvrez une page Web dans le navigateur, vous agissez en tant que consommateur de services et le serveur www agit en tant que fournisseur de services pour vous fournir une page Web. S'il s'agit d'une connexion normale, le client et le serveur effectuent tous les deux une poignée de main et lancent une session (appelée une connexion TCP).
Après cela, en fonction du comportement du serveur et du client, l'état passera à ESTABLISHED, IDLE, TIMEOUT, etc. Mais dans REST, nous utilisons le protocole HTTP qui est un état sans état, ce qui signifie que le serveur ne stockera aucune information de session sur le client. Le client est responsable de l'envoi de tous les détails requis par le serveur pour être réparé, c'est-à-dire lorsque nous invoquons l'URI http://somedomain:8080/senthil/services/page1 du serveur, il contient suffisamment de détails sur le client pour servir pleinement la page 1.
Transfert d'État
En utilisant le même exemple, lorsque vous ouvrez une page Web en utilisant une URL pour afficher un fichier image (RESSOURCE) sur le serveur, le serveur www vous montrera (au client) l'image dans un certain format, c'est-à-dire une REPRÉSENTATION de la RESSOURCE (fichier image ).
Au cours de ce processus, l'état constant de la ressource du serveur (c'est-à-dire l'état du fichier image qui est stocké dans le serveur base de données) sera représenté au client dans un format compréhensible, c'est-à-dire état de l'application du client. Ainsi, l'état de la ressource restera constant par rapport aux clients, et seule la représentation de la ressource changera, ce qui à son tour changerait l'état de l'application.
Enfin, la représentation de la ressource (comment l'image est affichée pour le client), qui modifie implicitement l'état du serveur et du client, est appelée REST.
Chaque objet a un état (données) et un comportement (méthodes) .Pour transférer l'état de l'objet sur le serveur à une instance particulière de temps au client, une sorte de représentation est nécessaire comme JSON ou xml ou tout autre format.
Donc REST consiste à créer une représentation de l'état actuel de l'objet et à transférer cette représentation sur le réseau.
Je pense que toute la question de la préoccupation du style architectural REST, revient à comprendre que l'auteur, Roy Fielding, avait en tête de proposer dans sa thèse, un ensemble de principes pour construire des architectures basées sur le paradigme hipertext ou hipermedia.
Ce paradigme, je pense, est la clé centrale pour comprendre ce sujet important.
Derrière le style d'organisation de l'architecture d'une application client-serveur proposé par Roy Fielding, je pense qu'il y a une idée spécifique d'une application client-serveur moderne, qui consiste en une sorte de moteur pour gouverner la transition d'état d'application, dont les états sont potentiellement extensibles à infini.
Dans cette vision, l'Ipertext\Ipermedia est le centre de tout le style architectural proposé par Fielding et le concept clé qui permet à ce paradigme de fonctionner est le "transfert représentationnel (état)".
Je pense que "représentationnelle" se réfère au concept de "transfert" , au lieu du concept de "état", c'est-à-dire que c'est le transfert pour être représentatif (de type représentatif), et c'est, à mon avis, la cause principale du nom de "Transfert de l'Etat Représentatif".
Ainsi, en concevant une application Restful, il s'agit d'abord de concevoir une architecture basée sur un réseau de composants, chacun communiquant avec d'autres dans un modèle d'architecture en couches client-serveur, en envoyant chacun d'entre eux une représentation de son état.
Ainsi, le front-end, premier client de cette architecture, transite par ses états montrant la représentation des états envoyés par le ou les composants, qu'il appelle endossant sur une interface cohérente uniforme et non sur une api "privée".
Un tel type d'application, dans l'esprit de l'auteur, est potentiellement extensible à des états infinis, car ses états ne dépendent pas d'une API privée, mais dépendent d'un univoque système d'identifiant (comme URI) partagé par tous les agents de cette architecture, sur quelques verbes pour gérer la transion de ses états et sur un système de transfert de représentation partagé convenu, ou plus.
Cette transition se termine par la communication de sa représentation au composant serveur appelé via les verbes qui composent l'API "publique", qui devrait appartenir au protocole de communication sans état utilisé par les composants client-serveur.
De cette manière, cette interaction composants client-serveur consiste à échanger (transférer, communiquer) des représentations des états des composants à l'aide d'un protocole sans état.
Et le concept central qui permet à toutes ces architectures de s'étendre potentiellement à l'infini est le transfert de représentation qui approuve leur architecture.
TL; DR
Representational state transfer ou simplement REST est un terme pour échanger des données dans des formats bien définis afin d'augmenter l'interopérabilité. Grâce à l'application de certaines contraintes, le découplage des clients vers les serveurs doit être réalisé, ce qui rend le premier plus robuste et celui-ci plus flexible aux changements.
Une représentation des ressources est le résultat de l'application d'un mappage de l'état actuel des ressources à une structure et une syntaxe bien définies des types de supports. Il est donc fortement couplé avec négociation de conten qui définit le processus d'accord sur un type de média pour transformer l'état des ressources en une représentation demandée (= syntaxe et structure).
REST peut être considéré comme une technique permettant de découpler les clients des serveurs/API dans un système distribué, ce qui donne au serveur la liberté d'évoluer et de modifier sa structure en fonction de ses besoins sans interrompre les implémentations client.
Pour obtenir un avantage aussi important, deux conditions préalables doivent être réunies, car presque rien n'est gratuit. Fielding a défini ici quelques contraintes qu'il a clarifiées (et expliquées) dans son blog bien conn . Les serveurs ne pourront pas obtenir une telle liberté si les clients ne suivent pas l'approche REST ainsi que les clients ne pourront pas explorer dynamiquement d'autres possibilités si le serveur ne prend pas en charge les clients dans En bref, les deux parties doivent suivre les mêmes principes.Si l'approche n'est pas rigoureuse, un couplage direct entre le serveur et les clients restera, ce qui entraînera des défaillances si le serveur devait changer.
Mais comment le découplage est-il réellement réalisé?
Tout d'abord, un serveur doit prendre en charge un client pour suivre sa tâche en incluant les URI que les clients peuvent utiliser. Le fait qu'un serveur fournisse tous les URI qu'un client peut invoquer à partir de l'état actuel du client supprime la nécessité pour le client d'avoir une connaissance a priori de l'API et de la structure des URI.
Deuxièmement, au lieu de laisser les clients interpréter les URI, les serveurs doivent renvoyer les URI en combinaison avec les noms des relations de liaison. C'est-à-dire au lieu d'un client utilisant (et interprétant) un URI comme http://server.org/api/orders il doit utiliser une relation de lien comme new-order. Si le serveur change l'URI ci-dessus, c'est-à-dire http://server.org/api/new-orders pour une raison quelconque, les clients utilisant des noms de relation de lien pourront toujours suivre leur tâche tandis que ceux utilisant directement l'URI auront besoin d'une mise à jour avant de pouvoir continuer.
À ma connaissance, il n'existe pas encore de normes pour définir et documenter ces noms de relation de lien. Pour les liens de collection, la sémantique des noms de relation comme self, prev, next, first et last semble être suffisamment significative même si quelque chose plus spécifique à un domaine comme order ou product-xyz Peut-être pas. Cette sémantique peut être décrite dans des types de supports spéciaux ou dans de nouvelles normes.
Jusqu'à présent, ces points s'attaquent à la contrainte HATEOAS mais malheureusement ce n'est pas encore tout. Selon le blog de Fieldings:
Une API REST doit consacrer presque tout son effort descriptif à définir le ou les types de support utilisés pour représenter les ressources et piloter l'état de l'application, ou pour définir des noms de relation étendus et/ou une marque activée par hypertexte -up pour les types de supports standard existants.
Mise en ligne d'un commentaire supplémentaire:
Une API REST ne doit jamais avoir de ressources "typées" importantes pour le client. Les auteurs de spécifications peuvent utiliser des types de ressources pour décrire l'implémentation du serveur derrière l'interface, mais ces types doivent être non pertinents et invisibles pour le client. Les seuls types significatifs pour un client sont le type de média de la représentation actuelle et les noms de relation standardisés.
A ressource typée est une ressource où un client a une présomption de contenu. C'est à dire. un client qui a reçu un URI http://server.org/api/user/sam+sample avec un nom de relation de lien user détermine que les données appartenant à cette ressource décrivent une personne et peuvent donc tenter de rassembler un application/json représentation des données de ressource dans un objet Person.
Le problème avec les ressources typées est que les clients ont certaines hypothèses ou connaissances pré-affectées sur les données contenues dans ces ressources, c'est-à-dire une ressource utilisateur qui peut varier d'un serveur à l'autre. Alors qu'un serveur peut exposer un nom d'utilisateur en tant que propriété name, un autre serveur peut utiliser firstName et lastName et un client qui souhaite mettre en service chaque possibilité est presque impossible à gérer. De plus, si le serveur change un jour, ses clients logiques peuvent casser avec une certaine probabilité. Pour contrer ce couplage, les types de supports doivent être utilisés à la place.
Les types de supports, qui sont une description textuelle lisible par l'homme d'un format de représentation, définissent la syntaxe utilisée ainsi que la structure et la sémantique des éléments disponibles contenus dans les documents échangés dans ce format. Les applications qui suivent le modèle d'architecture REST doivent donc utiliser établi ou des types de supports personnalisés pour augmenter l'interopérabilité. Au lieu de coupler directement le client et le serveur, les deux se couplent aux types de supports en réalité. La prise en charge de ces types de supports peut être fournie soit en chargeant des bibliothèques existantes, soit en implémentant la spécification à partir de zéro. Même le chargement dynamique de ces types de supports via des plugins est possible, si pris en charge.
Les clients et les serveurs doivent utiliser négociation de conten pour convenir d'un format de type de support commun compris par les deux parties pour échanger l'état actuel d'une ressource. La négociation de contenu est obtenue en fournissant un en-tête HTTP Accept (et/ou l'un de ses frères et sœurs), qui répertorie les types MIME qu'un client est capable ou désireux de traiter, dans la demande et par le serveur répondant soit en un seul des formats demandés dont un Content-Type En-tête de réponse HTTP pour informer le client de la représentation de type de support réellement utilisée ou renvoyer un 406 réponse d'échec.
Pour l'exemple de la personne ci-dessus, les clients peuvent envoyer un en-tête HTTP Accept avec le contenu suivant: application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1 au serveur, qui demande au serveur de renvoyer l'état de la ressource dans une syntaxe et une structure définies par l'un des types de média répertoriés. Il spécifie en outre que le client préfère recevoir l'état formaté selon la spécification du application/vcard+json description du type de support et si le serveur ne le peut pas, il devrait préférer hal + json à la syntaxe json traditionnelle. Le serveur mappe maintenant l'état de la ressource actuelle à l'un des formats demandés ou répond par un 406 message d'échec si tous les types de supports demandés sont inconnus ou que l'état n'a pas pu être converti en une telle structure ou représentation par défaut prise en charge par le client.
Pour résumer, REST est une technique utilisée pour atteindre une interopérabilité élevée en s'appuyant sur des types de supports bien définis et pour découpler les clients des serveurs en utilisant des fonctionnalités telles que la négociation de contenu et HATEOAS. En récompense, les clients deviendront robustes aux changements et nécessitent donc moins de maintenance en général tandis que le serveur a l'avantage de pouvoir évoluer et changer sans avoir à craindre que les clients ne puissent plus interagir avec lui une fois que les changements auront été mis en ligne.
Certaines choses comme les noms de relation de lien significatifs normalisés, les types de supports personnalisés dépendant du domaine et les processus de mappage pour transformer l'état en représentations applicables au type de support doivent d'abord être configurées, ce qui est une tâche non triviale TBH, bien qu'une fois disponibles, ils offrent les avantages mentionnés ci-dessus.
La signification du TRANSFERT D'ÉTAT DE REPRÉSENTATION est le REPOS
RESTful a mis DIRECT VERB dans le serveur
Dans un exemple de considération réelle, la valeur mise en VERBE a généralement HTTP GET et POST
A un protocole SIMPLE un peu comme le SOAP (a beaucoup de complexité!)
Si la réponse n'est pas satisfaisante, veuillez fournir une question plus élaborée
REST a beaucoup de sujets à discuter, est le sujet de nombreux blogs et livres
Imaginez un diagramme d'état - ce qui suit fera l'affaire.
S'il s'agissait de l'ensemble de pages Web, vous commenceriez à Page de destination de premier cycle pour un étudiant. Selon le diagramme, lorsque vous cliquerez sur le lien "Suivant", il vous amènera à la page Freshman - en supposant que l'étudiant a obtenu son diplôme. En cliquant plusieurs fois sur "Suivant", vous accédez à la dernière page.
Bien sûr, il pourrait y avoir d'autres transitions comme "Accueil" vous permettant de passer à la page par défaut.
L'état visible du site Web n'a rien à voir avec la façon dont le serveur implémente cette association en interne - c'est-à-dire les états internes. Cela peut impliquer plusieurs bases de données, serveurs et autres. Un étudiant peut obtenir son diplôme et son statut peut avoir été mis à jour via d'autres méthodes. Le client n'est pas au courant de ces détails - mais peut toujours s'attendre à obtenir un état visible cohérent (défini) pour la consommation humaine (ou machine).
Un autre exemple: lorsque vous regardez cette page, vous vous trouvez dans un "emplacement" particulier identifiable et reproductible dans la hiérarchie Web StackOverFlow.
Ainsi, RESTful State s'occupe de la navigation.