1 00:00:03,880 --> 00:00:06,815 Permettetemi di iniziare dandovi 2 00:00:06,815 --> 00:00:11,165 una rapida introduzione di 10 minuti agli Essentials of Networking. 3 00:00:11,165 --> 00:00:14,045 Dato che abbiamo un tempo limitato, 4 00:00:14,045 --> 00:00:16,355 vorrei concentrarmi sul fornirvi 5 00:00:16,355 --> 00:00:21,191 gli elementi essenziali di cui avete bisogno per comprendere ciascuno degli argomenti. 6 00:00:21,191 --> 00:00:26,240 Ora, ciò che copriamo in questo particolare modulo richiederà 7 00:00:26,240 --> 00:00:30,230 almeno una comprensione rudimentale di come 8 00:00:30,230 --> 00:00:34,255 funziona la rete di computer prima di capire perché abbiamo bisogno di usare HTTP, 9 00:00:34,255 --> 00:00:36,700 perché comunichiamo con un server, 10 00:00:36,700 --> 00:00:42,485 qual è la ragione del ritardo quando si parla con un server e così via. 11 00:00:42,485 --> 00:00:45,920 Inoltre, i vari protocolli di 12 00:00:45,920 --> 00:00:50,335 cui è necessario essere a conoscenza prima di poter comunicare con un server. 13 00:00:50,335 --> 00:00:53,540 Quindi, tenendo a mente tutto questo, 14 00:00:53,540 --> 00:00:58,945 una rapida introduzione di 10 minuti agli Essentials of Networking. 15 00:00:58,945 --> 00:01:03,600 Iniziamo a renderci conto che le applicazioni web non sono più stand-alone. 16 00:01:03,600 --> 00:01:11,030 Hanno sempre un preventivo nudo backend Cloud che supporta la tua applicazione web. 17 00:01:11,030 --> 00:01:13,535 Ora, in questi giorni, tutto è sul Cloud. 18 00:01:13,535 --> 00:01:15,500 Presto sarai anche tu sul Cloud, 19 00:01:15,500 --> 00:01:19,455 almeno sulla nuvola nove con un rivestimento argentato. 20 00:01:19,455 --> 00:01:23,785 Ma, dato che abbiamo bisogno di 21 00:01:23,785 --> 00:01:29,090 un supporto lato server per la nostra applicazione angolare per funzionare correttamente, 22 00:01:29,090 --> 00:01:31,295 ci vorresti ospitare il server. 23 00:01:31,295 --> 00:01:36,405 E in questi giorni, l'hosting del server è molto 24 00:01:36,405 --> 00:01:42,575 semplice utilizzando uno dei servizi di infrastruttura basati sul cloud, 25 00:01:42,575 --> 00:01:48,260 cose come Amazon Web Services o Heroku o Digital 26 00:01:48,260 --> 00:01:55,190 Ocean o molti altri che forniscono supporto server basato su cloud. 27 00:01:55,190 --> 00:01:59,235 Quindi, cosa è esattamente disponibile sul lato server? 28 00:01:59,235 --> 00:02:06,744 In genere si dispone di un frontend server che sta parlando con l'applicazione angolare, 29 00:02:06,744 --> 00:02:14,615 quindi questa è la logica del server e dietro le quinte la logica del server comunica con 30 00:02:14,615 --> 00:02:23,665 uno storage persistente come un database in cui i dati vengono archiviati e recuperati. 31 00:02:23,665 --> 00:02:26,130 Quando entri nel mondo del networking, 32 00:02:26,130 --> 00:02:31,064 sarai presto bombardato con 304 piccoli acronimi, 33 00:02:31,064 --> 00:02:36,230 cose che pensavi di sapere cosa fossero dal normale inglese o hanno 34 00:02:36,230 --> 00:02:38,360 un significato o uno 35 00:02:38,360 --> 00:02:42,375 scopo completamente diverso quando li incontri in quel mondo di networking. 36 00:02:42,375 --> 00:02:44,470 Quindi esaminiamo alcuni di loro. 37 00:02:44,470 --> 00:02:49,020 Così nel mondo del networking si sente la gente parlare su protocollo HTTP. 38 00:02:49,020 --> 00:02:53,215 Protocollo utilizzato per comunicare tra il client e il server. 39 00:02:53,215 --> 00:02:56,960 Questo è un protocollo a livello di applicazione di 40 00:02:56,960 --> 00:03:01,135 cui parleremo brevemente un po 'di più nel resto di questa lezione. 41 00:03:01,135 --> 00:03:07,550 Il protocollo HTTP per funzionare necessita di un URL da fornire, 42 00:03:07,550 --> 00:03:09,715 l'Uniform Resource Locator. 43 00:03:09,715 --> 00:03:15,205 Quindi questa è una stringa di caratteri separati da barre, 44 00:03:15,205 --> 00:03:22,355 con due punti HTTP o due punti HTTPS attaccati davanti ad esso. 45 00:03:22,355 --> 00:03:25,547 E sono sicuro che se hai usato il World Wide Web, 46 00:03:25,547 --> 00:03:29,395 hai abbastanza familiarità con l'aspetto degli URL. 47 00:03:29,395 --> 00:03:33,230 Ora, inoltre, sentiresti persone parlare di JSON, 48 00:03:33,230 --> 00:03:38,380 non del tuo amico Jason ma della notazione degli oggetti JavaScript. 49 00:03:38,380 --> 00:03:43,610 Quindi la notazione dell'oggetto JavaScript è un modo per codificare i dati che 50 00:03:43,610 --> 00:03:49,660 vengono spediti dal lato server al lato client o viceversa. 51 00:03:49,660 --> 00:03:54,320 E sentirete anche le persone parlare di XML ancora un altro modo di 52 00:03:54,320 --> 00:04:01,205 codificare i dati mentre è in transito spedizione tra il lato client e server. 53 00:04:01,205 --> 00:04:08,375 Ora, sentirai anche le persone parlare di protocolli di livello superiore chiamati SOAP, 54 00:04:08,375 --> 00:04:14,045 non del tipo con cui fai la doccia, ma SOAP come protocollo che 55 00:04:14,045 --> 00:04:21,975 consente la comunicazione tra entità di distribuzione all'interno della loro rete. 56 00:04:21,975 --> 00:04:25,295 E inoltre, sentirai le persone parlare di REST, 57 00:04:25,295 --> 00:04:29,505 non qualcosa che ottieni troppo passando attraverso questo particolare corso, 58 00:04:29,505 --> 00:04:32,510 REST o Representational State Transfer. 59 00:04:32,510 --> 00:04:36,200 Avrò una lezione più breve 60 00:04:36,200 --> 00:04:40,970 specificamente dedicata a REST un po 'più tardi in questo modulo. 61 00:04:40,970 --> 00:04:42,905 E nel mondo HTTP, 62 00:04:42,905 --> 00:04:45,990 sentiresti persone parlare di GET, PUT 63 00:04:45,990 --> 00:04:50,210 , POST e DELETE e ti staresti chiedendo, 64 00:04:50,210 --> 00:04:52,200 cosa significano tutti? 65 00:04:52,200 --> 00:04:55,250 Impariamo un po 'di questi in 66 00:04:55,250 --> 00:05:01,245 questa lezione e anche la lezione su REST che vedrai un po 'più tardi. 67 00:05:01,245 --> 00:05:05,020 Una cosa importante che è necessario comprendere quando si 68 00:05:05,020 --> 00:05:10,120 comunica con un server è che la comunicazione del server client 69 00:05:10,120 --> 00:05:15,130 causa quantità impreviste di ritardi o quantità indeterminata di ritardo 70 00:05:15,130 --> 00:05:21,340 mentre i dati vengono recuperati o caricati sul server dal sito client. 71 00:05:21,340 --> 00:05:23,270 Quindi, il che significa che all'interno dell'applicazione del sito client, è 72 00:05:23,270 --> 00:05:27,310 necessario mantenere l'utente informato sul fatto che 73 00:05:27,310 --> 00:05:31,750 qualcosa sta succedendo dietro le quinte ed essere 74 00:05:31,750 --> 00:05:35,335 in grado di gestire i ritardi e 75 00:05:35,335 --> 00:05:41,020 possibilmente non essere in grado di ottenere i dati dal lato server. 76 00:05:41,020 --> 00:05:45,490 È del tutto possibile che quando si tenta di connettersi a un server, 77 00:05:45,490 --> 00:05:47,765 la connessione del server potrebbe non riuscire, 78 00:05:47,765 --> 00:05:53,920 il server potrebbe restituire dati errati o potrebbe causare un errore nella comunicazione. 79 00:05:53,920 --> 00:05:58,750 Tutti questi devono essere gestiti dal lato client in modo appropriato in modo che l'applicazione 80 00:05:58,750 --> 00:06:04,450 continui a funzionare anche in presenza di questi problemi. 81 00:06:04,450 --> 00:06:09,250 Il protocollo Hypertext Transfer Protocol, 82 00:06:09,250 --> 00:06:12,880 utilizzato per comunicare tra il client e il server, 83 00:06:12,880 --> 00:06:15,405 il protocollo di trasferimento ipertestuale. 84 00:06:15,405 --> 00:06:18,585 Ma questo è un protocollo di comunicazione client server. 85 00:06:18,585 --> 00:06:20,800 Ora questo può o non può 86 00:06:20,800 --> 00:06:23,532 avere molto senso per te a meno che tu non abbia uno sfondo sufficiente nella rete, 87 00:06:23,532 --> 00:06:28,480 ma questo è un protocollo che viene utilizzato per codificare i messaggi che hai 88 00:06:28,480 --> 00:06:31,330 scambiato tra l'applicazione client che è 89 00:06:31,330 --> 00:06:35,375 un'applicazione angolare in questo caso e un lato server. 90 00:06:35,375 --> 00:06:38,620 Quindi questo protocollo HTTP consente di 91 00:06:38,620 --> 00:06:42,450 recuperare documenti basati su ipertesto dal lato server, 92 00:06:42,450 --> 00:06:47,200 sempre più le informazioni scaricate dal lato server sono 93 00:06:47,200 --> 00:06:52,495 codificate in uno dei formati di codifica standard come JSON o XML. 94 00:06:52,495 --> 00:06:55,750 E per poter parlare con un server, 95 00:06:55,750 --> 00:07:04,180 hai il supporto di varie azioni HTTP o ciò che chiamiamo verbi HTTP, 96 00:07:04,180 --> 00:07:07,135 HEAD, GET, POST, 97 00:07:07,135 --> 00:07:11,020 PUT, DELETE, TRACE, OPTIONS e CONNECT. 98 00:07:11,020 --> 00:07:14,080 Vedremo in particolare i 99 00:07:14,080 --> 00:07:24,395 verbi GET, PUT, POST e DELETE in modo più dettagliato quando esaminiamo il protocollo API REST un po 'più tardi. 100 00:07:24,395 --> 00:07:27,670 Come funziona il protocollo HTTP? 101 00:07:27,670 --> 00:07:30,010 Nel protocollo HTTP, 102 00:07:30,010 --> 00:07:35,215 si sta inviando richiesta GET dall'applicazione client al server. 103 00:07:35,215 --> 00:07:39,780 E questo è codificato sotto forma di un messaggio di richiesta HTTP. 104 00:07:39,780 --> 00:07:43,760 Il messaggio di richiesta in genere contiene un URL 105 00:07:43,760 --> 00:07:48,995 nel messaggio di richiesta che indica che cosa si desidera che il lato server invii. 106 00:07:48,995 --> 00:07:52,660 E questo è in genere un messaggio GET se si desidera che 107 00:07:52,660 --> 00:07:57,440 i dati vengano scaricati dal lato server. 108 00:07:57,440 --> 00:08:02,110 Specificherai anche con quale server stai comunicando. 109 00:08:02,110 --> 00:08:04,864 Quando il server riceve la richiesta, 110 00:08:04,864 --> 00:08:09,325 il server recupererà i dati dalla sua archiviazione dati, 111 00:08:09,325 --> 00:08:11,980 in genere un database sul lato server, 112 00:08:11,980 --> 00:08:14,250 quindi impacchetterà questi dati in 113 00:08:14,250 --> 00:08:20,420 un formato appropriato e invierà i dati sul lato client. 114 00:08:20,420 --> 00:08:23,285 Se stai ottenendo 115 00:08:23,285 --> 00:08:25,240 codice HTML, CSS e JavaScript standard dal lato server, 116 00:08:25,240 --> 00:08:27,310 allora il tuo browser è in grado di renderizzarlo. 117 00:08:27,310 --> 00:08:30,144 Ma con applicazioni come Angular, 118 00:08:30,144 --> 00:08:32,830 ti connetti principalmente al server e quindi 119 00:08:32,830 --> 00:08:39,700 recuperi dati sotto forma di JSON o XML la maggior parte del tempo. 120 00:08:39,700 --> 00:08:44,200 Ad eccezione del download iniziale di tutte le risorse necessarie 121 00:08:44,200 --> 00:08:49,245 per l'esecuzione dell'applicazione Angular all'interno del browser. 122 00:08:49,245 --> 00:08:51,090 Quindi, come abbiamo visto in precedenza, 123 00:08:51,090 --> 00:08:59,139 l'applicazione HTTP richiede messaggi da inviare tra il client e il server. 124 00:08:59,139 --> 00:09:03,615 Un messaggio di richiesta viene in genere inviato dal client al server e 125 00:09:03,615 --> 00:09:09,500 il messaggio di richiesta è costituito da una riga di richiesta più un gruppo di intestazioni, 126 00:09:09,500 --> 00:09:14,170 in cui si forniscono informazioni aggiuntive per qualificare la richiesta. 127 00:09:14,170 --> 00:09:17,410 Vedremo l'uso di varie intestazioni e impostazioni 128 00:09:17,410 --> 00:09:23,425 nelle intestazioni mentre passiamo attraverso alcuni degli esercizi in questo particolare modulo. 129 00:09:23,425 --> 00:09:27,045 La riga di richiesta e le intestazioni sono separate dal corpo 130 00:09:27,045 --> 00:09:31,280 del messaggio di richiesta da una riga vuota. 131 00:09:31,280 --> 00:09:34,300 Il corpo del messaggio può contenere dati aggiuntivi, 132 00:09:34,300 --> 00:09:38,460 soprattutto se il client sta inviando dati sul lato server. 133 00:09:38,460 --> 00:09:40,735 Ad esempio, quando si invia un modulo, 134 00:09:40,735 --> 00:09:45,190 le informazioni all'interno del modulo vengono codificate in 135 00:09:45,190 --> 00:09:51,115 un formato JSON e quindi inviate al lato server dal lato client. 136 00:09:51,115 --> 00:09:55,640 Quindi questo sarà fatto usando un messaggio POST o PUT. 137 00:09:55,640 --> 00:10:00,374 Guardando i piccoli dettagli del messaggio di richiesta HTTP, 138 00:10:00,374 --> 00:10:02,500 il tipico messaggio di richiesta nella 139 00:10:02,500 --> 00:10:06,140 riga di richiesta conterrà il metodo che è GET, PUT, POST, 140 00:10:06,140 --> 00:10:10,225 DELETE o alcuni degli altri verbi che hai visto in precedenza, 141 00:10:10,225 --> 00:10:13,735 e quindi seguito dall'URL e dalla versione 142 00:10:13,735 --> 00:10:19,260 del Protocollo HTTP che si sta utilizzando per comunicare dal client al lato server. 143 00:10:19,260 --> 00:10:23,250 Il campo intestazione in genere contiene un nome di campo di intestazione 144 00:10:23,250 --> 00:10:27,310 , due punti e il valore per tale campo di intestazione. 145 00:10:27,310 --> 00:10:30,020 E il contenuto del corpo, come ho detto, 146 00:10:30,020 --> 00:10:36,090 potrebbe essere codificato in formato JSON o XML. 147 00:10:36,090 --> 00:10:39,355 Ecco un esempio di 148 00:10:39,355 --> 00:10:46,040 un tipico messaggio di richiesta HTTP che può essere inviato al server dal client. 149 00:10:46,040 --> 00:10:48,000 Quindi, in questo particolare messaggio di richiesta, 150 00:10:48,000 --> 00:10:52,540 stiamo chiedendo al server di mantenere la pagina index.html dal 151 00:10:52,540 --> 00:10:55,150 lato server al lato client in modo che 152 00:10:55,150 --> 00:10:58,100 possa essere renderizzata nel browser sul lato client. 153 00:10:58,100 --> 00:11:03,790 Una richiesta come questa avrebbe in genere un corpo vuoto nel messaggio di richiesta. 154 00:11:03,790 --> 00:11:06,460 La maggior parte delle informazioni verrà codificata 155 00:11:06,460 --> 00:11:11,755 nella riga di richiesta più le intestazioni del messaggio di richiesta. 156 00:11:11,755 --> 00:11:15,935 Quando il client invia la richiesta al server. 157 00:11:15,935 --> 00:11:22,120 Il server elaborerà la richiesta e quindi invierà una risposta al lato client. 158 00:11:22,120 --> 00:11:26,150 Il messaggio di risposta è organizzato in tre parti, 159 00:11:26,150 --> 00:11:30,850 una riga di stato in cui vengono 160 00:11:30,850 --> 00:11:35,648 memorizzate alcune informazioni su come la richiesta è stata elaborata e ciò che viene inviato al client, 161 00:11:35,648 --> 00:11:40,270 le intestazioni conterranno ulteriori dettagli di ciò che è 162 00:11:40,270 --> 00:11:45,145 contenuto nel messaggio di risposta e quindi seguita da una riga vuota 163 00:11:45,145 --> 00:11:49,355 e quindi dal corpo effettivo del messaggio. 164 00:11:49,355 --> 00:11:55,405 Un esempio di ciò che sarebbe in genere contenuto in un messaggio di risposta HTTP, 165 00:11:55,405 --> 00:11:59,875 in questo caso, questo messaggio di risposta sta tornando con un 200, 166 00:11:59,875 --> 00:12:03,260 che è un codice di stato del messaggio. 167 00:12:03,260 --> 00:12:07,420 Se viene visualizzato un 200 nella riga di richiesta come codice di stato, 168 00:12:07,420 --> 00:12:11,770 significa che la richiesta ha avuto esito positivo e 169 00:12:11,770 --> 00:12:16,920 che il server è in grado di restituire i dati richiesti dal lato server. 170 00:12:16,920 --> 00:12:22,180 E quindi l'intestazione conterrà indicazioni aggiuntive 171 00:12:22,180 --> 00:12:25,165 sul lato client incluse informazioni su 172 00:12:25,165 --> 00:12:29,425 come viene codificato il corpo effettivo del messaggio. 173 00:12:29,425 --> 00:12:31,705 Quindi il corpo potrebbe contenere, 174 00:12:31,705 --> 00:12:34,565 se è stata richiesta la pagina index.html, 175 00:12:34,565 --> 00:12:39,670 il corpo del messaggio conterrà il codice HTML per 176 00:12:39,670 --> 00:12:45,515 la pagina index.html come si vede in questo esempio qui. 177 00:12:45,515 --> 00:12:53,955 Una delle informazioni nella riga di stato a cui mi riferisco come codice di stato. 178 00:12:53,955 --> 00:12:58,080 Se il server è in grado di elaborare correttamente la tua richiesta, 179 00:12:58,080 --> 00:13:01,852 invierà una risposta con un codice di stato di 200, 180 00:13:01,852 --> 00:13:04,330 il che significa che tutto va bene sul lato server e 181 00:13:04,330 --> 00:13:07,685 il lato server sta restituendo i dati correttamente. 182 00:13:07,685 --> 00:13:12,055 Se il server non è in grado di elaborare la richiesta per qualsiasi motivo, 183 00:13:12,055 --> 00:13:14,800 le informazioni verranno codificate 184 00:13:14,800 --> 00:13:20,020 nel codice di stato nella riga di stato del messaggio di risposta. 185 00:13:20,020 --> 00:13:24,160 I vari codici di stato in genere che si incontrano quando si 186 00:13:24,160 --> 00:13:28,355 riceve una risposta dal lato server includono un 201, il 187 00:13:28,355 --> 00:13:30,985 che significa che quando si tenta di creare 188 00:13:30,985 --> 00:13:34,540 un oggetto sul lato server è stato creato con successo, 189 00:13:34,540 --> 00:13:39,100 o un 301 che significa che qualsiasi cosa si sta richiedendo è stato spostato in modo permanente 190 00:13:39,100 --> 00:13:42,365 a una nuova posizione e l'URL 191 00:13:42,365 --> 00:13:46,965 della nuova posizione di tale risorsa verrà restituito al lato client. 192 00:13:46,965 --> 00:13:52,775 400s e 500s in genere indicano che c'è qualche problema sul lato server. 193 00:13:52,775 --> 00:13:57,310 404 è qualcosa che si incontra spesso quando 194 00:13:57,310 --> 00:14:02,260 si richiede qualcosa che non esiste sul lato server. 195 00:14:02,260 --> 00:14:05,620 Allo stesso modo, 500 significa che il server si sta solo arrendendo, 196 00:14:05,620 --> 00:14:10,390 non è in grado di elaborare la richiesta e quindi invia un errore interno del server. 197 00:14:10,390 --> 00:14:14,445 Questi sono due codici di errore comuni che si incontrano. 198 00:14:14,445 --> 00:14:20,355 I restanti hanno un significato specifico come elencato in questa tabella qui. 199 00:14:20,355 --> 00:14:24,483 Ci sono più dei codici di stato che ti ho dato in questa tabella, 200 00:14:24,483 --> 00:14:27,963 ma questi sono alcuni dei codici di stato più comuni che 201 00:14:27,963 --> 00:14:32,835 incontrerai in un messaggio di risposta proveniente dal lato server. 202 00:14:32,835 --> 00:14:37,420 Un altro punto che ho menzionato è il fatto che il server può codificare 203 00:14:37,420 --> 00:14:46,880 i dati in un formato specifico come XML o Extended Markup Language o JSON, 204 00:14:46,880 --> 00:14:50,845 il formato JavaScript Object Notation. 205 00:14:50,845 --> 00:14:53,950 Ora in genere, in questo particolare corso, 206 00:14:53,950 --> 00:14:57,700 ci occuperemo di dati che sono codificati principalmente in JSON. 207 00:14:57,700 --> 00:15:02,875 La maggior parte delle applicazioni lato client, 208 00:15:02,875 --> 00:15:06,680 incluse le applicazioni mobili, in genere comunicano con 209 00:15:06,680 --> 00:15:16,515 il server e il formato di scambio dei dati è JSON per impostazione predefinita nella maggior parte dei casi. 210 00:15:16,515 --> 00:15:22,125 Questo è il motivo per cui passerò alcuni minuti a spiegarti su JSON. 211 00:15:22,125 --> 00:15:27,785 Il JavaScript Object Notation o JSON è un formato di interscambio dati leggero. 212 00:15:27,785 --> 00:15:33,100 Il motivo per cui il formato dei dati JSON è particolarmente 213 00:15:33,100 --> 00:15:38,685 interessante per noi in questo corso è perché la notazione degli oggetti JavaScript, 214 00:15:38,685 --> 00:15:40,710 come suggerisce il nome, si 215 00:15:40,710 --> 00:15:46,840 mappa molto facilmente in un oggetto JavaScript che si utilizza con qualsiasi codice JavaScript. 216 00:15:46,840 --> 00:15:50,430 Quindi convertire un oggetto JavaScript 217 00:15:50,430 --> 00:15:53,725 in notazione JSON e viceversa è molto semplice. 218 00:15:53,725 --> 00:15:57,420 La notazione JSON è ciò che chiamiamo come una 219 00:15:57,420 --> 00:16:01,815 notazione autodescrittiva e molto facile da capire. 220 00:16:01,815 --> 00:16:05,103 Nel formato JavaScript Object Notation, 221 00:16:05,103 --> 00:16:11,040 i dati sono strutturati in modo molto pulito e specificato. 222 00:16:11,040 --> 00:16:14,693 Questo è strutturato come una raccolta di nomi, coppie di valori, 223 00:16:14,693 --> 00:16:19,610 e questo è strutturato come un elenco ordinato di valori. 224 00:16:19,610 --> 00:16:23,375 Puoi vedere un esempio di questo sul lato destro qui. 225 00:16:23,375 --> 00:16:30,750 Abbiamo effettivamente utilizzato questi dati JSON all'interno della nostra applicazione angolare già in precedenza. 226 00:16:30,750 --> 00:16:35,570 Quindi, ora capisci perché i dati sono strutturati in questo modo. 227 00:16:35,570 --> 00:16:41,220 E ti rendi conto anche che è molto facile essere in grado di gestire 228 00:16:41,220 --> 00:16:47,850 questi dati all'interno del tuo JavaScript o del tuo codice TypeScript nella tua applicazione Angular. 229 00:16:47,850 --> 00:16:55,000 Con questo, completa una rapida panoramica degli elementi essenziali per la rete.