Laissez-moi vous reposer brièvement. Je t'ai eu là.
Ce que je voulais dire, c'est que je vous donne
un bref aperçu du transfert d'État de représentation.
Qu' est-ce que REST exactement ?
Comment l'utiliser dans notre application React,
et comment l'utiliser pour communiquer avec le serveur ?
Comment un serveur prend-il en charge l'API REST
et comment accéder à l'API REST à partir de notre application React ?
Parlons un peu plus de ça dans cette leçon.
Je suis sûr que vous avez souvent entendu parler du terme « services Web » dans le monde de l'informatique.
Que sont exactement les services Web ?
Les services Web sont une façon de concevoir des systèmes pour prendre en charge l'interopérabilité
entre les systèmes connectés sur un réseau tel qu'Internet comme nous le voyons aujourd'hui.
C' est ce que nous appelons une architecture orientée service.
Maintenant, cela signifie que vous fournissez
un moyen normalisé pour que deux machines connectées à Internet puissent
communiquer entre elles au
niveau de la couche d'application pour les applications Web utilisant des standards ouverts.
Maintenant, j'ai utilisé beaucoup de jargon là-bas.
Essayons de les décomposer et de comprendre
un peu à propos de chacun de cela dans cette conférence.
Deux approches communes utilisées pour la prise en charge des services Web sont SOAP.
Les services Web basés sur le protocole d'accès aux objets simples qui utilisent
le langage de description des services Web pour
spécifier la façon dont les deux points de terminaison communiquent entre eux.
En règle générale, SOAP est basé sur
l'utilisation de XML comme format pour les messages échangés entre les deux points de terminaison.
Representational State Transfer ou REST utilise également des normes Web,
mais l'échange de données entre les deux points de terminaison pourrait être XML ou de
plus en plus utiliser JSON comme format.
La méthode d'interopérabilité REST est plus simple que SOAP et par conséquent,
REST a trouvé un déploiement beaucoup plus large dans le monde des services Web.
Généralement, la communication client-serveur est
facilitée à l'aide de REST où le serveur prend en charge une API REST et
le client peut alors appeler les points de terminaison de l'API REST
afin d'obtenir des informations ou de télécharger des informations sur le serveur.
Encore une fois, j'ai mentionné le mot invoquer les points de terminaison de l'API REST,
donc ce sont quelques termes que j'ai utilisés.
Clarifions certains d'entre eux dans les prochaines diapositives.
Representational State Transfer est un style d'architecture logicielle
spécialement conçu pour les hypermédias distribués sur le World Wide Web.
Maintenant cela a été introduit par Roy Fielding dans sa thèse de doctorat.
Maintenant, c'est l'une de ces thèses de doctorat
qui a produit quelque chose d'utile pour le monde.
Donc, cela a retrouvé beaucoup de traction dans le monde des services Web.
Il s'agit d'un ensemble de principes réseau qui décrivent comment les
ressources peuvent être mises à disposition sur les serveurs
et ces ressources peuvent être accessibles à partir des clients
en identifiant les ressources à l'aide de points de terminaison d'API de repos.
Dans le cadre du transfert d'État de représentation,
il existe quatre principes de base de la conception.
Tout d'abord, REST est construit sur le protocole HTTP,
donc il utilise toutes les méthodes HTTP que nous avons déjà vues dans la leçon précédente.
Deuxièmement, REST est conçu pour être sans état,
ce qui signifie que le serveur ne stocke aucune information sur
l'état une fois la communication terminée.
Donc, quand un serveur reçoit la requête, le serveur répond,
puis il ne se souvient
plus de rien de la conversation entre le client et le serveur.
Troisièmement, la façon REST de fournir des ressources consiste à
exposer une structure de répertoire comme des URL (Uniform Resource Locators - URL).
Quatrièmement, le format d'échange de données est généralement JSON
ou XML, ou les deux peuvent être pris en charge à l'aide de REST.
Une des motivations pour Roy suggérant REST comme moyen de soutenir les services Web est
qu'il capture toutes les choses qui sont bonnes sur
le World Wide Web et qui ont fait du World Wide Web un succès.
Utilisation d'indicateurs de ressources
uniformes ou d'URL (Uniform Resource Locators) qui vous permettent d'
adresser des ressources en les spécifiant sous forme d'URL.
Le second, étant un protocole qui vit au-dessus du protocole HTTP.
HTTP a déjà trouvé un large déploiement sur Internet.
Troisièmement, le cycle de réponse de requête pour lequel HTTP est bien connu.
Ainsi, vous envoyez une demande,
le serveur reçoit votre demande, traite la demande,
envoie la réponse à la demande,
et le client reçoit la réponse,
agit sur cela et peut générer d'autres demandes.
Donc, cette approche du cycle de réponse à la demande est très
bien établie avec HTTP et le World Wide Web.
Maintenant, le protocole HTTP comme nous l'avons vu précédemment,
nous allons utiliser tous les différents verbes que HTTP fournit.
plus précisément, GET, PUT,
POST et DELETE pour pouvoir
spécifier les opérations à effectuer sur les ressources stockées côté serveur.
Par exemple, si vous effectuez une requête HTTP GET,
vous demandez au serveur de renvoyer la ressource.
Si vous effectuez une requête POST,
vous demandez au serveur de créer une nouvelle ressource.
Si vous effectuez une requête PUT,
vous demandez au serveur de mettre à jour une ressource existante.
Et si vous émettez une requête DELETE,
vous demandez au serveur de supprimer la ressource
qui est identifiée par l'URL particulière.
En outre, il essaie de préserver l'idempotence.
Certaines opérations, lorsqu'elles sont effectuées même à plusieurs reprises,
ne provoquent aucun changement d'état.
Certaines autres opérations, si vous les faites successivement,
elles peuvent provoquer un changement d'état.
Vous devez donc être prudent quant aux opérations qui peuvent être répétées
sans conséquences dommageables et qui doivent être faites avec soin.
Dans le monde REST, vous entendez souvent des gens parler de noms, de verbes et de représentations.
Maintenant, nous allons clarifier chacune d'entre elles un peu plus en détail dans les prochaines diapositives. Les
noms font spécifiquement référence aux ressources et ces ressources sont
généralement identifiées par leurs URL et celles-ci ne sont pas contraintes. Les
verbes sont des contraintes et ceux-ci spécifient les actions à
faire sur les ressources et les représentations comme nous le voyons.
Lorsque les informations doivent être transmises
du serveur au client ou du client au serveur,
comment vous encodez les informations.
Généralement, soit en utilisant JSON ou XML. La
ressource est l'abstraction clé autour de laquelle REST fonctionne.
Ainsi, l'information est abstraite sous la forme d'une ressource et la ressource
est identifiée en la spécifiant à l'aide d'une URL.
Ainsi, toute information qui peut être encapsulée et rendue disponible,
peut être identifiée comme une ressource.
Une information comme la météo actuelle à Hong Kong pourrait être une ressource, une
image pourrait être une ressource, une
information sur le cours des actions pourrait être une ressource, et ainsi de suite.
Ainsi, tout ce que vous définissez comme un élément d'information susceptible d'intéresser un client,
peut être identifié comme une ressource.
Vous pouvez même traiter les ressources en tant que collection de
ressources que le serveur peut envoyer au client.
Un exemple de la façon dont vous nommez les ressources est illustré ici.
Nous utilisons donc des URI pour identifier la source.
Une lecture rapide de ces spécifications ou des URI ici
vous permettra facilement de comprendre ce à quoi nous faisons référence en utilisant ces URI.
Ainsi, par exemple, quelque chose qui se termine par des plates/,
vous supposez automatiquement que cela fait référence à une collection de plats.
Mais plats/123 par exemple,
pourrait signifier le numéro de plat 123 dans ce cas et ainsi de suite.
Donc, il est très facile à enregistrer et vous pouvez spécifier
une collection de ressources et être en mesure de
les identifier comme une collection, puis les télécharger comme une collection ou vous pouvez
identifier une ressource individuelle et dire que vous voulez cette ressource particulière.
Maintenant, ces ressources peuvent être organisées dans une hiérarchie de la spécification de cet URI.
Ainsi, au fur et à mesure que
vous traversez le chemin, vous passez du plus général au plus spécifique de la ressource.
Cette structure de répertoires vous permet d'identifier
très facilement les ressources que vous utilisez ou fournissez à partir de votre serveur.
La deuxième partie de l'API REST sont les verbes.
En particulier, nous sommes intéressés par les quatre verbes de HTTP GET,
PUT, POST et DELETE.
Dans ce cas, ces verbes seront mappés en actions que nous
voulons effectuer sur la ressource, côté serveur.
Un GET signifierait que vous souhaitez effectuer une opération de lecture sur la ressource.
Donc, ce qui signifie qu'un client envoyant une requête GET indique au serveur qu'il
veut obtenir une représentation
de cette ressource du côté serveur vers le côté client.
Un POST signifie que vous voulez créer
une nouvelle ressource, puis vous spécifiez les détails de la ressource
dans la représentation utilisée pour
spécifier la ressource, puis envoyez ces informations sur le côté serveur, de
sorte que le serveur créera cette ressource en votre nom.
Un PUT serait une modification des ressources et
une DELETE comme vous vous attendez est la suppression des ressources.
Ainsi, comme vous pouvez le voir, les quatre verbes
, GET, POST, PUT et DELETE,
sont mappés dans les quatre opérations CRUD que vous pouvez
effectuer sur une base de données qui stocke ces ressources côté serveur, les
opérations READ, CREATE, UPDATE et DELETE.
Plus en détail, le GET HTTP est un moyen de spécifier que vous
voulez que les informations ou
la représentation de la ressource soient renvoyées au client à partir du côté serveur.
Ainsi, lorsque vous émettez une requête GET à un point de terminaison d'API REST,
vous demandez soit un ensemble de ressources représentées par
URI, soit une ressource spécifique qui est identifiée par l'ID de cette ressource particulière,
spécifié dans l'URL.
Donc, comme vous le voyez dans cet exemple,
si vous dites, plates/452,
vous voulez dire que le plat numéro 452 avec
l'ID 452 doit être retourné côté client.
De même, l'opération POST comme nous l'avons vu est utilisée pour créer la ressource.
Ainsi, lorsque vous créez la ressource,
le contenu de la description de la ressource se présente sous la forme d'une représentation JSON ou
d'une représentation XML et sera inclus dans
le corps du message de requête qui est envoyé au côté serveur.
Ainsi, une opération POST attend une représentation de
la ressource au format JSON ou XML dans le corps du message de requête.
Lorsque le serveur reçoit ce message de demande,
le serveur crée cette ressource côté serveur, puis renvoie
une conformation ou une erreur pour indiquer que la création de la ressource a échoué.
De même, une opération PUT est utilisée pour mettre à jour une ressource.
Lorsque vous effectuez une opération PUT sur une ressource côté serveur,
vous pouvez renvoyer la modification
soit en spécifiant uniquement la modification partielle que vous souhaitez affecter à
la ressource particulière dans le corps du message de réponse, soit vous pouvez envoyer
la représentation complète de la dans le corps du message.
Selon l'arrangement entre le client et le serveur,
le serveur s'attend à ce que les informations soient transmises dans le corps du message de requête.
Une opération DELETE comme vous vous attendez supprime la ressource existante.
Maintenant, dans ce cas particulier,
bien sûr, une opération DELETE serait idempotente car si vous
essayez de supprimer une ressource et que la ressource existe, elle sera supprimée.
Si vous essayez de supprimer une ressource non existante,
cela ne provoquera aucune modification supplémentaire sur le côté serveur,
sauf que le serveur répondra avec une erreur indiquant que la ressource n'existe pas.
Mais, néanmoins, DELETE est un exemple d'opération idempotente dans ce cas.
De même, l'opération GET est également une opération idempotente car elle
n'apporte aucune modification à la ressource côté serveur.
POST et PUT vont bien sûr modifier la ressource côté serveur,
soit créer une nouvelle ressource ou modifier une ressource existante côté serveur.
Bien sûr, les représentations,
comme je l'ai souligné,
les deux formats communs de représentation sont soit JSON soit XML.
La dernière partie que nous devons souligner est
que le côté serveur doit être complètement sans état,
ce qui signifie que le côté serveur ne suit pas l'
état du client car si le serveur a besoin de suivre l'état des clients,
il ne sera pas évolutif.
Ainsi, pour une implémentation évolutive du côté serveur,
vous utilisez normalement un serveur sans état côté serveur.
Ainsi, chaque requête que le client envoie au serveur sera
traitée comme une requête indépendante et
ne reflètera pas les requêtes précédentes
qui ont déjà été traitées par le serveur à partir de ce client particulier.
Donc, il est de la responsabilité du client de suivre son propre état,
soit sous la forme d'utiliser des cookies ou d'utiliser une base de données côté client,
quel que soit le moyen approprié.
Maintenant, cette approche où le client suit son propre état est
beaucoup plus évolutive car chaque client individuel
sera responsable du suivi de son propre état.
C' est là que la configuration MVC côté client nous aide à cet égard.
Enfin, nous n'avons pas encore fini avec REST.
Nous verrons plus de REST dans les exercices qui suivent dans cette leçon particulière
, puis nous verrons aussi plus de détails sur l'utilisation de REST dans le reste de ce cours.