Permettez-moi tout d'abord de vous
présenter rapidement 10 minutes à l'Essentials of Networking.
Étant donné que nous avons peu de temps,
je me concentrerais sur vous fournir
les éléments essentiels dont vous avez besoin pour comprendre chacun des sujets.
Maintenant, ce que nous couvrons dans ce module particulier nécessitera
au moins une compréhension rudimentaire du
fonctionnement des réseaux informatiques avant de comprendre pourquoi nous devons utiliser HTTP,
pourquoi nous communiquons avec un serveur,
quelle est la raison du retard lorsque vous parlez à un serveur, etc.
Et aussi, les différents protocoles dont vous
devez être conscient avant de pouvoir même communiquer avec un serveur.
Donc, en gardant tout cela à l'esprit,
une introduction rapide de 10 minutes aux Essentials of Networking.
Nous commençons à comprendre que les applications Web ne sont plus autonomes.
Ils ont toujours un devis sans devis dorsal Cloud supportant votre application web.
De nos jours, tout est sur le Cloud.
Très bientôt, vous serez aussi sur le Cloud,
au moins sur le nuage neuf avec une doublure argentée.
Mais, étant donné que nous avons besoin
d'un support côté serveur pour que notre application angulaire fonctionne correctement,
il y aurait lieu d'héberger le serveur.
De nos jours, l'hébergement du serveur se
fait très facilement en utilisant l'un des services d'infrastructure basés sur le cloud, des
choses comme Amazon Web Services ou Heroku ou Digital
Ocean ou bien d'autres qui fournissent la prise en charge des serveurs basés sur le cloud.
Alors, qu'est-ce qui est exactement disponible côté serveur ?
Vous avez généralement un frontend de serveur qui parle à votre application angulaire,
donc c'est la logique du serveur et dans les coulisses, la logique du serveur communique avec
un stockage persistant comme une base de données où vos données sont stockées et récupérées.
Lorsque vous entrez dans le monde du réseautage,
vous serez bientôt bombardé de 304 petits acronymes, des
choses que vous pensiez savoir ce qu'ils étaient de l'anglais normal ou qu'ils ont
un sens ou un
but entièrement différent lorsque vous les rencontrez dans ce monde de réseautage.
Examinons quelques-uns d'entre eux.
Donc, dans le monde de la mise en réseau, vous entendrez les gens parler sur le protocole HTTP.
Protocole utilisé pour communiquer entre le client et le serveur.
Il s'agit d'un protocole de couche d'application dont nous
parlerons brièvement un peu plus dans le reste de cette conférence.
Le protocole HTTP pour qu'il fonctionne nécessite une URL pour lui être fournie,
le Uniform Resource Locator.
Il s'agit donc d'une chaîne de caractères séparés par des barres obliques,
avec un deux-points HTTP ou un deux-points HTTPS attaché devant lui.
Et je suis sûr que si vous avez utilisé le World Wide Web,
vous êtes assez familier avec ce à quoi ressemblent les URL.
Maintenant, en outre, vous entendriez des gens parler de JSON,
pas votre ami Jason mais JavaScript Object Notation.
Donc, la notation d'objet JavaScript est une façon d'encoder les données qui
sont expédiées du côté serveur vers le côté client ou vice versa.
Et aussi, vous entendrez les gens parler de XML encore une autre façon de
coder les données pendant qu'il est en transit expédition entre le client et le serveur.
Maintenant, vous entendrez également des gens parler de protocoles de niveau supérieur appelés SOAP,
pas du genre avec lequel vous prenez une douche, mais SOAP comme un protocole qui
permet la communication entre les entités de distribution au sein de leur réseau.
Et aussi, vous entendrez des gens parler de REST,
pas quelque chose que vous obtenez trop passer par ce cours particulier,
REST ou Représentational State Transfer.
J' aurai une conférence plus courte
spécifiquement consacrée à REST un peu plus tard dans ce module.
Et dans le monde HTTP,
vous entendiez des gens parler de GET, PUT
, POST et DELETE et vous vous demandez,
que signifient-ils tous ?
Apprenons un peu à ce sujet dans
cette conférence et aussi la conférence sur REST que vous verrez un peu plus tard.
Une chose importante que vous devez comprendre lorsque vous
communiquez avec un serveur est que la communication du serveur client
provoque des retards inattendus ou un délai indéterminé
pendant que les données sont récupérées ou téléchargées sur le serveur à partir du site client.
Donc, ce qui signifie que dans votre application de site client,
vous devez tenir l'utilisateur informé du fait que
quelque chose se passe dans les coulisses et être
capable de gérer les retards et
peut-être de ne pas pouvoir obtenir les données du côté serveur.
Il est tout à fait possible que lorsque vous essayez de vous connecter à un serveur,
la connexion du serveur peut échouer,
le serveur peut renvoyer des données incorrectes ou peut provoquer une erreur de communication.
Tous ces éléments doivent être gérés du côté client de manière appropriée afin que
votre application continue de fonctionner même en présence de ces problèmes.
Sauter dans le protocole de couche d'application le plus populaire
utilisé pour communiquer entre le client et le serveur,
le protocole de transfert hypertexte.
Mais il s'agit d'un protocole de communication de serveur client.
Maintenant, cela peut ou peut ne pas avoir beaucoup de sens pour vous,
sauf si vous avez suffisamment d'arrière-plan dans la mise en réseau,
mais c'est un protocole qui est utilisé pour coder les messages que vous avez
échangés entre votre application cliente qui est
une application angulaire dans ce cas et un côté serveur.
Donc, ce protocole HTTP vous permet de
récupérer des documents basés sur l'hypertexte du côté serveur, de
plus en plus les informations téléchargées du côté serveur sont
codées dans l'un des formats de codage standard comme JSON ou XML.
Et pour pouvoir parler à un serveur,
vous avez le support de diverses actions HTTP ou ce que nous appelons les verbes HTTP,
HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS, et CONNECT.
Nous verrons en particulier les
verbes GET, PUT, POST et DELETE plus en détail lorsque nous examinons le protocole API REST un peu plus tard.
Comment fonctionne le protocole HTTP ?
Dans le protocole HTTP,
vous envoyez la requête GET de votre application cliente au serveur.
Et cela est encodé sous la forme d'un message de requête HTTP.
Le message de demande contient généralement une URL dans
le message de demande indiquant ce que vous voulez que le côté serveur vous envoie.
Et il s'agit généralement d'un message GET si vous voulez que
les données soient téléchargées à partir du serveur.
Vous spécifiez également le serveur avec lequel vous communiquez.
Lorsque le serveur reçoit votre demande,
le serveur récupère les données de son stockage de données,
généralement une base de données côté serveur,
puis empaquète ces données dans
un format approprié et vous renvoie les données côté client.
Si vous obtenez du
code HTML, CSS et JavaScript standard du côté serveur
, votre navigateur est en mesure de le rendre.
Mais avec des applications comme Angular,
vous vous connectez principalement au serveur, puis
récupérez des données sous la forme de JSON ou XML la plupart du temps.
Sauf pour le téléchargement initial de toutes les ressources nécessaires
à l'exécution de votre application Angular dans votre navigateur.
Ainsi, comme nous l'avons vu précédemment,
l'application HTTP nécessite l'envoi de messages entre le client et le serveur.
Un message de demande est généralement envoyé du client au serveur et
le message de demande se compose d'une ligne de demande ainsi que d'un tas d'en-têtes,
où vous fournissez des informations supplémentaires pour qualifier la demande.
Nous verrons l'utilisation de divers en-têtes et paramètres dans
les en-têtes lorsque nous passons par certains des exercices dans ce module particulier.
La ligne de demande et les en-têtes sont séparés du corps
du message de demande par une ligne vide.
Le corps du message peut contenir des données supplémentaires,
en particulier si votre client envoie des données vers le serveur.
Par exemple, lorsque vous soumettez un formulaire,
les informations contenues dans le formulaire sont codées dans
un format JSON, puis envoyées vers le serveur à partir du côté client.
Donc, cela sera fait en utilisant un message POST ou PUT.
En regardant le peu plus de détails du message de requête HTTP,
le message de requête typique dans
la ligne de requête contiendra la méthode qui est GET,
PUT, POST, DELETE ou certains des autres verbes que vous avez vus précédemment,
puis suivie de l'URL et de la version de
la protocole HTTP que vous utilisez pour communiquer du client au côté serveur.
Le champ d'en-tête contient généralement un nom de champ d'en-tête,
deux points et la valeur de ce champ d'en-tête.
Et le contenu du corps, comme je l'ai mentionné,
pourrait être encodé en format JSON ou XML.
Voici un exemple de
message de requête HTTP typique qui peut être envoyé au serveur à partir du client.
Donc, dans ce message de demande particulier,
nous demandons au serveur de conserver la page index.html
du côté serveur vers le côté client afin qu'elle
puisse être rendue dans le navigateur du côté client.
Une requête comme celle-ci aurait généralement un corps vide dans le message de requête.
La plupart des informations seront codées dans
la ligne de demande ainsi que les en-têtes du message de demande.
Lorsque le client envoie la requête au serveur.
Le serveur traite la demande, puis renvoie une réponse au côté client.
Le message de réponse est organisé en trois parties,
une ligne d'état où des informations sur
la façon dont la demande a été traitée et ce qui est renvoyé au client sont stockées,
les en-têtes contiendront des détails supplémentaires sur ce qui est
contenu dans le message de réponse, puis suivi d'une ligne vide,
puis du corps réel du message.
Un exemple de ce qui serait généralement contenu dans un message de réponse HTTP,
dans ce cas, ce message de réponse revient avec un 200,
qui est un code d'état du message.
Si vous voyez un 200 dans la ligne de demande comme code d'état,
cela signifie que votre requête a réussi et que le serveur est en mesure de
renvoyer les données que vous avez demandées du côté serveur.
Et puis l'en-tête contiendra des directions supplémentaires vers
le côté client, y compris des informations sur
la façon dont le corps réel du message est codé.
Ensuite, le corps peut contenir,
si vous avez demandé la page index.html,
le corps du message contiendra le code HTML de
la page index.html comme vous le voyez dans cet exemple ici.
L' un des éléments d'information de la ligne d'état que je désigne comme le code d'état.
Si le serveur est capable de traiter votre demande correctement,
il enverra une réponse avec un code d'état de 200,
ce qui signifie que tout va bien du côté serveur et
que le côté serveur renvoie les données correctement.
Si le serveur n'est pas en mesure de traiter la demande pour une raison quelconque
, ces informations seront encodées dans
le code d'état dans la ligne d'état du message de réponse.
Les différents codes d'état généralement que vous rencontrerez lorsque vous
recevez une réponse du côté serveur incluent un 201,
ce qui signifie que lorsque vous essayez de créer
un objet côté serveur, il a été créé avec succès,
ou un 301 ce qui signifie que tout ce que vous demandez a déplacé
de manière permanente à un nouvel emplacement et
l'URL du nouvel emplacement de cette ressource sera renvoyée à votre client.
Les 400 et 500 indiquent généralement qu'il y a un problème côté serveur.
404 est quelque chose que vous rencontrez souvent lorsque
vous demandez quelque chose qui n'existe pas du côté serveur.
De même, 500 signifie que le serveur abandonne simplement,
il est incapable de traiter votre demande, puis renvoie une erreur de serveur interne.
Ce sont deux codes d'erreur courants que vous rencontrerez.
Les autres ont une signification spécifique comme indiqué dans ce tableau ici.
Il y a plus que les codes d'état que je vous ai donnés dans ce tableau,
mais ce sont quelques-uns des codes d'état les plus courants que vous
rencontrerez dans un message de réponse venant du côté serveur.
Un autre point que j'ai mentionné est le fait que le serveur peut encoder
les données dans un format spécifique comme XML ou Extended Markup Language ou JSON,
le format JavaScript Object Notation.
Maintenant, généralement, dans ce cours particulier,
nous allons traiter des données qui sont encodées principalement en JSON.
La plupart des applications côté client
, y compris les applications mobiles, communiquent généralement avec
le serveur et le format d'échange de données est JSON par défaut dans la plupart des cas.
C' est la raison pour laquelle je vais passer quelques minutes à vous expliquer à propos de JSON.
JavaScript Object Notation ou JSON est un format d'échange de données léger.
La raison pour laquelle le format de données JSON est particulièrement
intéressant pour nous dans ce cours est que la notation d'objet JavaScript,
comme son nom l'indique,
se mappe très facilement dans un objet JavaScript que vous utilisez avec n'importe quel code JavaScript.
Donc, convertir un objet JavaScript
en notation JSON et vice versa est très simple.
La notation JSON est ce que nous appelons comme une
notation auto-descriptive et très facile à comprendre.
Dans le format JavaScript Object Notation,
les données sont structurées de manière très nette et précise.
Ceci est structuré comme une collection de noms, de paires de valeurs,
et ceci est structuré comme une liste ordonnée de valeurs.
Vous pouvez voir un exemple de ceci sur le côté droit ici.
Nous avons effectivement utilisé ces données JSON dans notre application angulaire déjà plus tôt.
Donc, maintenant vous voyez pourquoi les données sont structurées de cette façon.
Et vous réalisez également qu'il est très facile de pouvoir traiter
ces données dans votre code JavaScript ou votre code TypeScript dans votre application Angular.
Avec cela, je termine un bref aperçu des éléments essentiels de la mise en réseau.