Permettetemi di iniziare dandovi
una rapida introduzione di 10 minuti agli Essentials of Networking.
Dato che abbiamo un tempo limitato,
vorrei concentrarmi sul fornirvi
gli elementi essenziali di cui avete bisogno per comprendere ciascuno degli argomenti.
Ora, ciò che copriamo in questo particolare modulo richiederà
almeno una comprensione rudimentale di come
funziona la rete di computer prima di capire perché abbiamo bisogno di usare HTTP,
perché comunichiamo con un server,
qual è la ragione del ritardo quando si parla con un server e così via.
Inoltre, i vari protocolli di
cui è necessario essere a conoscenza prima di poter comunicare con un server.
Quindi, tenendo a mente tutto questo,
una rapida introduzione di 10 minuti agli Essentials of Networking.
Iniziamo a renderci conto che le applicazioni web non sono più stand-alone.
Hanno sempre un preventivo nudo backend Cloud che supporta la tua applicazione web.
Ora, in questi giorni, tutto è sul Cloud.
Presto sarai anche tu sul Cloud,
almeno sulla nuvola nove con un rivestimento argentato.
Ma, dato che abbiamo bisogno di
un supporto lato server per la nostra applicazione angolare per funzionare correttamente,
ci vorresti ospitare il server.
E in questi giorni, l'hosting del server è molto
semplice utilizzando uno dei servizi di infrastruttura basati sul cloud,
cose come Amazon Web Services o Heroku o Digital
Ocean o molti altri che forniscono supporto server basato su cloud.
Quindi, cosa è esattamente disponibile sul lato server?
In genere si dispone di un frontend server che sta parlando con l'applicazione angolare,
quindi questa è la logica del server e dietro le quinte la logica del server comunica con
uno storage persistente come un database in cui i dati vengono archiviati e recuperati.
Quando entri nel mondo del networking,
sarai presto bombardato con 304 piccoli acronimi,
cose che pensavi di sapere cosa fossero dal normale inglese o hanno
un significato o uno
scopo completamente diverso quando li incontri in quel mondo di networking.
Quindi esaminiamo alcuni di loro.
Così nel mondo del networking si sente la gente parlare su protocollo HTTP.
Protocollo utilizzato per comunicare tra il client e il server.
Questo è un protocollo a livello di applicazione di
cui parleremo brevemente un po 'di più nel resto di questa lezione.
Il protocollo HTTP per funzionare necessita di un URL da fornire,
l'Uniform Resource Locator.
Quindi questa è una stringa di caratteri separati da barre,
con due punti HTTP o due punti HTTPS attaccati davanti ad esso.
E sono sicuro che se hai usato il World Wide Web,
hai abbastanza familiarità con l'aspetto degli URL.
Ora, inoltre, sentiresti persone parlare di JSON,
non del tuo amico Jason ma della notazione degli oggetti JavaScript.
Quindi la notazione dell'oggetto JavaScript è un modo per codificare i dati che
vengono spediti dal lato server al lato client o viceversa.
E sentirete anche le persone parlare di XML ancora un altro modo di
codificare i dati mentre è in transito spedizione tra il lato client e server.
Ora, sentirai anche le persone parlare di protocolli di livello superiore chiamati SOAP,
non del tipo con cui fai la doccia, ma SOAP come protocollo che
consente la comunicazione tra entità di distribuzione all'interno della loro rete.
E inoltre, sentirai le persone parlare di REST,
non qualcosa che ottieni troppo passando attraverso questo particolare corso,
REST o Representational State Transfer.
Avrò una lezione più breve
specificamente dedicata a REST un po 'più tardi in questo modulo.
E nel mondo HTTP,
sentiresti persone parlare di GET, PUT
, POST e DELETE e ti staresti chiedendo,
cosa significano tutti?
Impariamo un po 'di questi in
questa lezione e anche la lezione su REST che vedrai un po 'più tardi.
Una cosa importante che è necessario comprendere quando si
comunica con un server è che la comunicazione del server client
causa quantità impreviste di ritardi o quantità indeterminata di ritardo
mentre i dati vengono recuperati o caricati sul server dal sito client.
Quindi, il che significa che all'interno dell'applicazione del sito client, è
necessario mantenere l'utente informato sul fatto che
qualcosa sta succedendo dietro le quinte ed essere
in grado di gestire i ritardi e
possibilmente non essere in grado di ottenere i dati dal lato server.
È del tutto possibile che quando si tenta di connettersi a un server,
la connessione del server potrebbe non riuscire,
il server potrebbe restituire dati errati o potrebbe causare un errore nella comunicazione.
Tutti questi devono essere gestiti dal lato client in modo appropriato in modo che l'applicazione
continui a funzionare anche in presenza di questi problemi.
Il protocollo Hypertext Transfer Protocol,
utilizzato per comunicare tra il client e il server,
il protocollo di trasferimento ipertestuale.
Ma questo è un protocollo di comunicazione client server.
Ora questo può o non può
avere molto senso per te a meno che tu non abbia uno sfondo sufficiente nella rete,
ma questo è un protocollo che viene utilizzato per codificare i messaggi che hai
scambiato tra l'applicazione client che è
un'applicazione angolare in questo caso e un lato server.
Quindi questo protocollo HTTP consente di
recuperare documenti basati su ipertesto dal lato server,
sempre più le informazioni scaricate dal lato server sono
codificate in uno dei formati di codifica standard come JSON o XML.
E per poter parlare con un server,
hai il supporto di varie azioni HTTP o ciò che chiamiamo verbi HTTP,
HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS e CONNECT.
Vedremo in particolare i
verbi GET, PUT, POST e DELETE in modo più dettagliato quando esaminiamo il protocollo API REST un po 'più tardi.
Come funziona il protocollo HTTP?
Nel protocollo HTTP,
si sta inviando richiesta GET dall'applicazione client al server.
E questo è codificato sotto forma di un messaggio di richiesta HTTP.
Il messaggio di richiesta in genere contiene un URL
nel messaggio di richiesta che indica che cosa si desidera che il lato server invii.
E questo è in genere un messaggio GET se si desidera che
i dati vengano scaricati dal lato server.
Specificherai anche con quale server stai comunicando.
Quando il server riceve la richiesta,
il server recupererà i dati dalla sua archiviazione dati,
in genere un database sul lato server,
quindi impacchetterà questi dati in
un formato appropriato e invierà i dati sul lato client.
Se stai ottenendo
codice HTML, CSS e JavaScript standard dal lato server,
allora il tuo browser è in grado di renderizzarlo.
Ma con applicazioni come Angular,
ti connetti principalmente al server e quindi
recuperi dati sotto forma di JSON o XML la maggior parte del tempo.
Ad eccezione del download iniziale di tutte le risorse necessarie
per l'esecuzione dell'applicazione Angular all'interno del browser.
Quindi, come abbiamo visto in precedenza,
l'applicazione HTTP richiede messaggi da inviare tra il client e il server.
Un messaggio di richiesta viene in genere inviato dal client al server e
il messaggio di richiesta è costituito da una riga di richiesta più un gruppo di intestazioni,
in cui si forniscono informazioni aggiuntive per qualificare la richiesta.
Vedremo l'uso di varie intestazioni e impostazioni
nelle intestazioni mentre passiamo attraverso alcuni degli esercizi in questo particolare modulo.
La riga di richiesta e le intestazioni sono separate dal corpo
del messaggio di richiesta da una riga vuota.
Il corpo del messaggio può contenere dati aggiuntivi,
soprattutto se il client sta inviando dati sul lato server.
Ad esempio, quando si invia un modulo,
le informazioni all'interno del modulo vengono codificate in
un formato JSON e quindi inviate al lato server dal lato client.
Quindi questo sarà fatto usando un messaggio POST o PUT.
Guardando i piccoli dettagli del messaggio di richiesta HTTP,
il tipico messaggio di richiesta nella
riga di richiesta conterrà il metodo che è GET, PUT, POST,
DELETE o alcuni degli altri verbi che hai visto in precedenza,
e quindi seguito dall'URL e dalla versione
del Protocollo HTTP che si sta utilizzando per comunicare dal client al lato server.
Il campo intestazione in genere contiene un nome di campo di intestazione
, due punti e il valore per tale campo di intestazione.
E il contenuto del corpo, come ho detto,
potrebbe essere codificato in formato JSON o XML.
Ecco un esempio di
un tipico messaggio di richiesta HTTP che può essere inviato al server dal client.
Quindi, in questo particolare messaggio di richiesta,
stiamo chiedendo al server di mantenere la pagina index.html dal
lato server al lato client in modo che
possa essere renderizzata nel browser sul lato client.
Una richiesta come questa avrebbe in genere un corpo vuoto nel messaggio di richiesta.
La maggior parte delle informazioni verrà codificata
nella riga di richiesta più le intestazioni del messaggio di richiesta.
Quando il client invia la richiesta al server.
Il server elaborerà la richiesta e quindi invierà una risposta al lato client.
Il messaggio di risposta è organizzato in tre parti,
una riga di stato in cui vengono
memorizzate alcune informazioni su come la richiesta è stata elaborata e ciò che viene inviato al client,
le intestazioni conterranno ulteriori dettagli di ciò che è
contenuto nel messaggio di risposta e quindi seguita da una riga vuota
e quindi dal corpo effettivo del messaggio.
Un esempio di ciò che sarebbe in genere contenuto in un messaggio di risposta HTTP,
in questo caso, questo messaggio di risposta sta tornando con un 200,
che è un codice di stato del messaggio.
Se viene visualizzato un 200 nella riga di richiesta come codice di stato,
significa che la richiesta ha avuto esito positivo e
che il server è in grado di restituire i dati richiesti dal lato server.
E quindi l'intestazione conterrà indicazioni aggiuntive
sul lato client incluse informazioni su
come viene codificato il corpo effettivo del messaggio.
Quindi il corpo potrebbe contenere,
se è stata richiesta la pagina index.html,
il corpo del messaggio conterrà il codice HTML per
la pagina index.html come si vede in questo esempio qui.
Una delle informazioni nella riga di stato a cui mi riferisco come codice di stato.
Se il server è in grado di elaborare correttamente la tua richiesta,
invierà una risposta con un codice di stato di 200,
il che significa che tutto va bene sul lato server e
il lato server sta restituendo i dati correttamente.
Se il server non è in grado di elaborare la richiesta per qualsiasi motivo,
le informazioni verranno codificate
nel codice di stato nella riga di stato del messaggio di risposta.
I vari codici di stato in genere che si incontrano quando si
riceve una risposta dal lato server includono un 201, il
che significa che quando si tenta di creare
un oggetto sul lato server è stato creato con successo,
o un 301 che significa che qualsiasi cosa si sta richiedendo è stato spostato in modo permanente
a una nuova posizione e l'URL
della nuova posizione di tale risorsa verrà restituito al lato client.
400s e 500s in genere indicano che c'è qualche problema sul lato server.
404 è qualcosa che si incontra spesso quando
si richiede qualcosa che non esiste sul lato server.
Allo stesso modo, 500 significa che il server si sta solo arrendendo,
non è in grado di elaborare la richiesta e quindi invia un errore interno del server.
Questi sono due codici di errore comuni che si incontrano.
I restanti hanno un significato specifico come elencato in questa tabella qui.
Ci sono più dei codici di stato che ti ho dato in questa tabella,
ma questi sono alcuni dei codici di stato più comuni che
incontrerai in un messaggio di risposta proveniente dal lato server.
Un altro punto che ho menzionato è il fatto che il server può codificare
i dati in un formato specifico come XML o Extended Markup Language o JSON,
il formato JavaScript Object Notation.
Ora in genere, in questo particolare corso,
ci occuperemo di dati che sono codificati principalmente in JSON.
La maggior parte delle applicazioni lato client,
incluse le applicazioni mobili, in genere comunicano con
il server e il formato di scambio dei dati è JSON per impostazione predefinita nella maggior parte dei casi.
Questo è il motivo per cui passerò alcuni minuti a spiegarti su JSON.
Il JavaScript Object Notation o JSON è un formato di interscambio dati leggero.
Il motivo per cui il formato dei dati JSON è particolarmente
interessante per noi in questo corso è perché la notazione degli oggetti JavaScript,
come suggerisce il nome, si
mappa molto facilmente in un oggetto JavaScript che si utilizza con qualsiasi codice JavaScript.
Quindi convertire un oggetto JavaScript
in notazione JSON e viceversa è molto semplice.
La notazione JSON è ciò che chiamiamo come una
notazione autodescrittiva e molto facile da capire.
Nel formato JavaScript Object Notation,
i dati sono strutturati in modo molto pulito e specificato.
Questo è strutturato come una raccolta di nomi, coppie di valori,
e questo è strutturato come un elenco ordinato di valori.
Puoi vedere un esempio di questo sul lato destro qui.
Abbiamo effettivamente utilizzato questi dati JSON all'interno della nostra applicazione angolare già in precedenza.
Quindi, ora capisci perché i dati sono strutturati in questo modo.
E ti rendi conto anche che è molto facile essere in grado di gestire
questi dati all'interno del tuo JavaScript o del tuo codice TypeScript nella tua applicazione Angular.
Con questo, completa una rapida panoramica degli elementi essenziali per la rete.