Permettez-moi de commencer par vous donner une introduction rapide
10 minutes à l'essentiel de la mise en réseau.
Plus j'enseigne l'anglais, plus je me rends compte que juste pour utiliser leurs plus belles caractéristiques
d'angulaire, vous devez avoir une compréhension de tant de différents Fin connectés
avant même de pouvoir comprendre ce que vous faites avec angulaire.
Au moment où vous commencez à chasser chacun de ces Fin,
ils deviendront des cours entiers par eux-mêmes et bientôt,
Je finirai par vous enseigner tout leur programme d'informatique.
Mais étant donné que nous avons un temps limité,
, je vais me concentrer sur vous fournir l'essentiel
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 du réseau informatique
avant de comprendre pourquoi nous devons utiliser HTTP,
pourquoi nous communiquons avec un serveur.
La raison du retard est que lorsque vous parlez à un serveur,
et ainsi de suite.
Et aussi, les différents protocoles que vous devez connaître
avant même de pouvoir communiquer avec un serveur.
Donc, en gardant tout cela à l'esprit,
une introduction rapide de 10 minutes à l'essentiel de la mise en réseau.
Nous commençons à réaliser que les applications web ne sont plus autonomes.
Ils ont toujours un devis unquote back-end cloud supportant votre application web.
Maintenant, ces jours-ci, 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 Silverside pour que notre application angulaire fonctionne correctement,
vous hébergerez le serveur.
Et ces jours-ci, l'hébergement du serveur se fait très facilement en utilisant 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 un support de serveur basé sur le cloud
que vous pouvez exploiter pour fournir un support serveur pour votre application angulaire.
Donc, du côté serveur, qu'est-ce qui est exactement disponible du côté serveur ?
Vous avez généralement un serveur frontal 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.
Quand vous entrerez dans le monde du réseautage, vous serez bientôt bombardés
avec 304 petits acronymes.
Les choses que vous croyiez savoir ce qu'ils étaient de l'anglais
normal ou ils ont une signification entièrement différente
ou but lorsque vous les rencontrez dans le monde du réseautage.
Alors, examinons quelques-uns d'entre eux.
Ainsi, dans le monde de la mise en réseau, vous entendrez les gens parler du protocole HTTP.
Protocole utilisé pour communiquer entre le client et le serveur.
Ceci est 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 a besoin d'une URL pour lui être fournie,
le localisateur de ressources uniformes.
Donc, ceci est une chaîne de caractères séparés par des barres obliques avec dans chaque deux-points TTP,
sur un https : attaché devant lui.
Et je suis sûr que si vous êtes utilisé sur le web,
vous êtes assez familier avec ce que les URL ressemblent.
Maintenant, en plus, vous entendrez les gens parler de JSON,
pas à votre ami Jason mais JavaScript Object Notation.
Donc, la notation d'objet JavaScript est un moyen 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 d'encoder les données pendant qu'elles sont en transit
entre le site client et serveur.
Maintenant, et aussi vous entendrez les gens parler de protocoles de plus haut niveau appelés SOAP,
pas le genre avec lequel vous prenez une douche, mais SOAP en tant que protocole
qui permet la communication entre les entités de distribution au sein du réseau.
Et aussi, vous entendrez les gens parler de REST, pas quelque chose
que vous obtenez trop en passant par ce cours particulier.
REST ou un transfert d'État représentatif.
Je vais avoir une conférence plus courte spécifiquement consacrée
à REST un peu plus tard dans ce module.
Et dans le monde HTTP, vous entendrez les gens parler de GET,
PUT, POST et DELETE, et vous vous demanderiez,
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 client serveur provoque une quantité inattendue
de retards ou une quantité indéterminée de retard
pendant que les données sont récupérées ou téléchargées sur le serveur à partir du côté client.
Donc, ce qui signifie que dans votre application client-serveur
, vous devez tenir l'utilisateur informé du fait
que quelque chose se passe dans les coulisses et être en mesure de gérer les retards
et peut-être ne pas être en mesure d'obtenir les données du côté serveur.
Il est tout à fait possible que lorsque vous essayez de vous connecter à un serveur,
la connexion au serveur peut échouer,
le serveur peut renvoyer des données incorrectes ou peut provoquer une erreur dans la communication.
Tous ces éléments doivent être traités du côté client de manière appropriée afin
que votre application fonctionnera toujours même en présence de ces problèmes.
En sautant 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 client serveur.
Maintenant, cela peut ou peut ne pas avoir beaucoup de sens pour vous
sauf si vous avez suffisamment d'expérience en réseau, mais c'est un protocole
qui est utilisé pour encoder les messages que vous échangez 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 hypertextes
du côté serveur de plus en plus les informations téléchargées
du côté serveur sont encodé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 examinerons le protocole d'API reste un peu plus tard.
Comment fonctionne le protocole HTTP ?
Dans le protocole HTTP, vous envoyez une requête de votre application cliente au serveur
et celle-ci est codée sous la forme d'un message de requête HTTP.
Le message de demande porte 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 souhaitez télécharger des données à partir du site du serveur.
Et vous indiquerez également avec quel serveur particulier 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 empaqueter ces données dans un quatre dos approprié,
et vous renvoie les données côté client.
Si vous obtenez du code HTML, CSS et javascript standard du côté serveur,
alors votre navigateur est capable de le rendre.
Retour avec des applications comme angular, vous vous connectez principalement au serveur
, puis récupérez des données sous 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 l'application angulaire 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.
Message de demande généralement envoyé par le client au serveur,
et le message de demande se compose d'une ligne de demande plus 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 que nous passons par quelques
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 vos clients envoient des données côté serveur.
Par exemple, lorsque vous soumettez un formulaire,
les informations contenues dans le formulaire sont encodées au format JSON
puis envoyées au côté serveur du côté client.
Donc, cela sera fait en utilisant soit un message POST ou PUT.
En regardant un peu plus de détails sur le message de requête HTTP,
le message de requête typique dans la ligne de requête contiendra la méthode,
qui est soit GET, PUT, PAUSE, DELETE
ou certains des autres verbes que vous avez vus plus tôt.
Ensuite, suivi de l'URL et de la version du 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é au format JSON ou XML.
Voici un exemple de message de requête HTTP classique
qui peut être envoyé au serveur à partir du client.
Donc, dans ce message de demande particulier, nous demandons au serveur de conserver la page
et index.hmtl du côté serveur vers le côté client afin
qu'elle puisse être rendue dans le navigateur 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 encodées dans la ligne de demande plus les en-têtes
du message de demande.
Lorsque le client envoie la demande au serveur,
le serveur traitera 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 avec quelques informations sur la façon dont la demande a été traitée
et ce qui est renvoyé au client est stockée.
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.
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 ici, 200 dans la ligne de demande en tant que 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 instructions supplémentaires vers le côté client,
incluant des informations sur la façon dont le corps réel du message est encodé.
Ensuite, le corps peut contenir, si vous avez demandé la page HTML d'index,
le corps du message contiendra le code HTML
pour la page HTML de démarrage de l'index comme vous le voyez dans cet exemple ici.
Un des éléments d'information de la ligne d'état que j'appelle ce code d'état.
Si le serveur est capable de traiter votre demande correctement,
il enverra une réponse avec un score d'état de 200,
ce qui signifie que tout est correct du côté serveur,
et le côté serveur retourne les données correctement.
Si le serveur ne peut pas traiter la demande pour une raison quelconque,
alors cette information sera codée dans le code d'état dans
cette 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 301 ce qui signifie que tout ce que vous demandez
a déplacé de façon permanente vers un nouvel emplacement,
et que vous êtes sur le nouvel emplacement de cette ressource
sera retourné à votre côté client.Les
400s et 500s indiquent généralement qu'il y a des problèmes côté serveur.
A 404 est quelque chose que vous rencontrez souvent lorsque vous demandez
pour quelque chose qui n'existe pas côté serveur.
De même, un 500 signifie que le serveur abandonne tout simplement,
il est incapable de traiter votre demande et renvoie ensuite une erreur de serveur interne.
Ce sont deux codes d'erreur courants que vous rencontrerez.
Les autres ont une signification spécifique telle que listée 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 Extensible Markup Language ou JSON, le JavaScript
Object Notation pour cela.
Maintenant, typiquement dans ce cours particulier, nous allons traiter des données
qui sont encodées principalement en JSON.
La plupart des applications, les applications côté client y compris les applications mobiles de nos jours,
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 sur JSON.
La notation d'objet javascript, ou JSON, est un format d'échange de données léger.
La raison pour laquelle le format de données JSON nous intéresse spécifiquement dans ce cours est
parce 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.
Cette notation JSON est un, ce que nous appelons,
comme une notation auto-décrivant et très facile à comprendre.
Dans le format de notation d'objet javascript,
les données sont structurées d'une manière très propre et spécifiée.
Ceci est structuré comme une collection de paires nom/valeur,
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 avec 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 vous rendez compte aussi qu'il est très facile de pouvoir traiter ces données
dans votre audio javascript, dactylographié est pris dans votre application angulaire.
Avec cela, je complète un aperçu rapide de l'essentiel de la mise en réseau.
Nous allons maintenant passer à et exercer où nous allons mettre en place un serveur rudimentaire
qui était de servir des données que nous pouvons connecter à partir de notre application angulaire
puis échanger des données avec un serveur.
Maintenant, nous allons développer un serveur à part entière dans l'un des cours ultérieurs,
le code Node JS et le cours de développement côté serveur
qui viendrait comme un dernier cours dans cette spécialisation.