[MUSIQUE]
Laissez-moi vous donner un bref repos.
Vous y a eu !
Ce que je voulais dire était,
laissez-moi vous donner un bref aperçu du transfert d'État représentatif.
Qu'est-ce que le repos ?
Comment l'utilisons-nous dans notre application angulaire et
comment l'utilisons-nous pour communiquer avec le serveur ?
Comment un serveur prend-il en charge l'API REST et
comment accèderons-nous à l'API REST à partir de notre application Angular ?
Parlons un peu plus de cela dans cette leçon.
Dans cette conférence particulière, je vais vous donner un bref aperçu de REST.
Je suis sûr que vous avez souvent entendu le terme Services Web mentionner
dans le monde informatique.
Que sont exactement les services Web ?
Les services Web sont un moyen de concevoir des systèmes qui prennent en charge l'interopérabilité entre les systèmes
connectés sur un réseau, comme l'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 standardisé pour deux machines
connectées à Internet pour pouvoir communiquer entre elles.
Leur niveau de mise en page d'application pour les applications de base de données
utilisant des standards ouverts.
Maintenant, j'ai utilisé beaucoup de jargon là-bas.
Essayons de les décomposer et
comprendrons un peu chacun de cela dans cette conférence.
Deux approches courantes qui sont utilisées pour prendre en charge les services Web sont SOAP,
les services Web basés sur le protocole d'accès aux objets simples,
qui utilise le langage de description des services Web pour
spécifiant comment les deux points finaux communiquent les uns avec les autres.
Et généralement, soap est basé sur l'utilisation de XML comme
le format des messages échangés entre les deux points de terminaison.
Le transfert d'état de présentation ou le repos utilise également des standards web, mais l'échange
de données entre les deux points de terminaison pourrait être XML ou de plus en plus.
Utilisation de JSON comme format.
La façon REST d'interopérabilité est plus simple que SOAP et
, donc REST a trouvé un déploiement beaucoup plus large dans les services web restés.
Généralement, la communication du serveur client est facilitée à l'aide de REST
où le serveur prend en charge l'API REST et le client peut alors invoquer ses points de terminaison REST API
afin d'obtenir des informations ou de télécharger des informations sur le serveur.
Encore une fois, j'ai mentionné le mot, invoquez ce point de fin de l'API REST.
Ce sont donc 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 qui
est spécialement conçu pour les hypermédias distribués sur le World Wide Web.
Maintenant cela a été introduit pour la première fois par Roy Fielding dans sa thèse de doctorat.
Maintenant, c'est une de ces thèses de doctorat qui a produit
quelque chose d'utile pour le monde.
Cela a donc 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 sont accessibles depuis les clients
en identifiant les ressources à l'aide des points de terminaison de l'API REST.
Dans le transfert d'État représentationnel, il y a quatre principes de conception de base.
Tout d'abord, REST est construit sur le protocole HTTP.
Donc, il utilise toutes les méthodes HTTP que nous avons déjà vu 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 pas
d'informations sur l'état une fois la communication terminée.
Donc, quand un serveur reçoit la requête, le serveur répond et
ensuite, il ne se souvient plus de cette conversation
entre le client et le serveur.
Troisièmement, la façon REST de fournir des ressources est de
exposer une structure de répertoire comme les URL des localisateurs de ressources uniformes.
Et quatrièmement, leur format pour l'échange de données est généralement JSON ou
XML, ou les deux qui peuvent être pris en charge à l'aide de REST.
Une des motivations à la hausse suggérant REST comme un moyen de soutenir les services Web
est qu'il capture tout ce qui est bon de tout le World Wide Web.
Et cela a fait le succès du Word Wide Web.
L'utilisation d'indicateurs de ressources uniformes ou de localisateurs de ressources uniformes, URL,
qui vous permettent d'adresser des ressources en les spécifiant comme URL,
le second étant un protocole qui monte au-dessus du protocole HTTP.
HTTP a déjà trouvé un déploiement étendu sur Internet.
Troisièmement, le cycle de réponse à la demande pour lequel HTTP est bien connu.
Donc vous envoyez une demande, le serveur reçoit votre demande, traite la demande,
envoie la réponse à la demande, et ce 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 de la requête est très bien établie avec HTTP
et le Web mondial Le protocole HTTP comme nous l'avons vu plus tôt,
nous utiliserons tous les différents verbes que HTTP fournit.
Plus précisément, la porte mettre post supprimer.
Pour pouvoir spécifier les opérations à effectuer
sur les ressources stockées côté serveur.
Donc, par exemple, si vous faites une requête HTTP GET, vous demandez
le serveur pour renvoyer la source.
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 demande de suppression, vous demandez
au serveur de supprimer la ressource identifiée par cette URL particulière.
Aussi, il essaie de préserver l'idempotence.
Certaines opérations quand elles sont effectuées
Même à plusieurs reprises ne provoquent aucun changement d'état.
D'autres opérations, si vous les faites successivement,
elles peuvent provoquer un changement d'état.
Donc, vous devez être prudent sur les opérations qui peuvent être répétées sans
aucune conséquence néfaste.
Et ce qui doit être fait très soigneusement.
Dans le monde REST, vous entendez souvent des gens parler de noms, de verbes
et de représentations.
Maintenant, nous allons clarifier chacun de ces éléments un peu plus en détail dans les prochaines diapositives.
Noms, en particulier, ils sont pleins de ressources et
ces ressources sont généralement identifiées par leurs URL et celles-ci sont sans contraintes.
Les verbes sont contraints et ces actions spécifiées doivent être effectuées sur les ressources.
Et les présentations telles que nous voyons quand les informations doivent être transmises de
le serveur au client ou
du client au serveur, comment vous encodez les informations.
Généralement, soit en utilisant JSON, soit en utilisant XML.
Resource est l'abstraction clé que REST travaille autour de sorte que
que les informations sont abstractées dans la ressource.
Et la ressource est identifiée en la spécifiant à l'aide d'un URI.
Ainsi, toute information qui peut être encapsulée et
mise à disposition 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, etc.
Donc, tout ce que vous définissez comme une information qui peut intéresser un client
, peut être identifié comme une ressource.
Vous pouvez même traiter les ressources en tant que collection de ressources
que ce serveur peut envoyer à ce 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 la spécification ou des URL ici vous permettra de comprendre facilement ce à quoi nous faisons référence en utilisant ces URL.
Donc, par exemple, quelque chose qui se termine par des plates/,
, vous supposez automatiquement que cela fait référence à une collection de plats.
Comme les plats/123 par exemple,
peut signifier le plat numéro 123, dans ce cas et ainsi de suite.
Il est donc très facile de dire que vous pouvez spécifier une collection de ressources, et
être capable de les identifier comme une collection, puis de les télécharger comme une collection.
Ou bien, vous pouvez identifier une ressource individuelle, et
dit que vous voulez cette ressource particulière.
Maintenant, ces ressources peuvent être organisées dans une hiérarchie
cette spécification de cet URI.
Alors que vous traversez le chemin,
vous passez de la plus générale à la plus spécifique de cette ressource.
Cette structure d'annuaire vous permet d'identifier très facilement les ressources que
vous fournissez à partir de votre site de service.
La deuxième partie de l'API REST sont les mots.
En particulier, nous sommes intéressés par les 4 verbes de HTTP pour obtenir,
mettre, poster et supprimer.
Dans ce cas, ces verbes feront la sieste des actions que nous
voulons effectuer sur la ressource côté serveur.
GetT signifie que vous voulez effectuer une opération de lecture sur la ressource, ce qui signifie
qu'un client qui envoie une requête get indique au serveur qu'il souhaite
obtenir cette présentation de la source de données du site serveur vers le site client.
POST signifie que vous voulez créer une nouvelle ressource et alors vous le ferez.
Spécifiez les détails de la ressource dans la représentation, mais est utilisé pour
spécifiant la ressource.
Ensuite, envoyez les informations sur le côté serveur, afin
que le serveur crée la ressource en votre nom.
Un PUT serait une modification des ressources, et
delete, comme vous pouvez vous y attendre, est la suppression des sources.
Donc, comme vous pouvez le voir les quatre verbes obtenir, poster, mettre 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 de lecture, de création, de mise à jour et de suppression.
En développant plus loin, le HTTP GET est un moyen de spécifier.
Que vous souhaitez que les informations ou leur présentation de la ressource soient
retournées au client à partir du site serveur.
Donc, lorsque vous émettez une requête GET à un point de terminaison de l'API REST.
Vous demandez soit une collection de ressources qui sont présentées par
Uri ou une ressource spécifique qui est identifiée par l'ID de
ces ressources particulières spécifiées dans l'URL de sorte que vous voyez dans cet exemple,
si vous disais/452, vous voulez dire que le numéro de plat 452,
avec l'id 452 doit être retourné au 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 serait
sous la forme d'une représentation JSON ou d'une représentation XML, et cela serait
inclus dans le corps du message de requête envoyé au côté serveur.
Donc, une opération de post attend une représentation
de la ressource au format JSON ou XML dans le corps du message de requête.
Et le serveur reçoit un tel message de demande, le serveur crée cette ressource
côté serveur, puis renvoie une confirmation ou
une erreur pour indiquer que la création de la ressource a échoué.
De même, il a mis l'opération facile à utiliser 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 effectuer sur la ressource particulière dans le corps du message de réponse.
Ou vous pouvez envoyer la représentation complète de la ressource
dans le corps du message, selon l'arrangement entre le client et
le serveur, le serveur attend que les informations soient transmises
dans le corps du message de requête.
DELETE opération comme vous vous attendez supprime la ressource existante.
Maintenant, dans ce cas particulier, bien sûr, une opération de suppression serait parce que
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 du côté serveur Sauf
que le serveur répondra avec une erreur indiquant que la ressource n'existe pas.
Mais néanmoins, est un exemple d'opération dans ce cas.
De même, l'opération get fonctionnera également car elle n'apporte aucune modification à la ressource sur le site du serveur.
Les entrées postérieures vont bien sûr modifier la ressource côté serveur.
Vous devez créer une nouvelle ressource ou
modifier une ressource existante côté serveur, et bien sûr des présentations de données.
Comme je l'ai souligné, les deux repli communs pour
représentant est soit JSON 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.
Parce que, si le serveur doit suivre l'état du client, il ne sera pas évolutif.
Donc, pour une implémentation évolutive du côté serveur,
vous utilisez normalement un serveur sans état sur le côté serveur.
Donc, si la demande des clients envoyés au serveur sera traitée comme
une requête indépendante, et ne reflétera pas sur les requêtes
précédentes qui ont déjà été traitées par le serveur à partir du client particulier.
C'est donc la responsabilité du client de suivre son propre état.
Soit sous forme d'utilisation de cookies ou d'utilisation d'une base de données de site client.
Quel que soit le moyen qui convient.
Maintenant, cette approche où le client suit son propre état est beaucoup plus évolutive,
parce que votre client sera responsable du suivi des siens.
Et c'est là que la configuration MVC côté client nous aide à cet égard.
Et 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.
Et puis aussi,
, nous verrons plus de détails sur l'utilisation de REST dans le reste de ce cours.
[MUSIQUE]