Permettetemi di iniziare dandovi una rapida
introduzione di 10 minuti agli elementi essenziali del networking.
Più insegno l'inglese, più mi rendo conto che solo per usare le loro caratteristiche più belle
di angolare è necessario avere una comprensione di così tante diverse FIN connesse
prima di poter persino capire cosa stai facendo con angolare.
Nel momento in cui inizierai a inseguire ognuna di queste
FIN, diventeranno interi corsi per conto loro e molto presto
finirò per insegnarti tutto il loro curriculum di informatica.
Ma dato il fatto che abbiamo un tempo limitato,
mi concentrerò nel 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 è che 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 elementi essenziali del networking.
Iniziamo a renderci conto che le applicazioni web non sono più stand-alone.
Hanno sempre un preventivo nuvola back-end 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 Silverside 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
che puoi sfruttare per fornire supporto server per la tua applicazione angolare.
Quindi, sul lato server, cosa è esattamente disponibile sul lato server?
In genere si dispone di un front-end server che sta parlando con l'applicazione angolare.
Quindi, questa è la logica del server e dietro le quinte,
la logica del server sta comunicando con uno storage persistente come un database
in cui i tuoi dati vengono memorizzati e recuperati.
Quando entrerai 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 nel mondo del networking.
Quindi, esaminiamo alcuni di loro.
Quindi, nel mondo del networking sentirai la gente parlare sul 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 in ogni due punti TTP,
su un https: attaccato di fronte ad esso.
E sono sicuro che se si utilizza il world wide web,
si ha abbastanza familiarità con l'aspetto degli URL.
Ora, inoltre, sentirai persone parlare di JSON,
non al tuo amico Jason ma JavaScript Object Notation.
Quindi, la notazione dell'oggetto JavaScript è un modo per codificare i dati che vengono spediti
dal lato server al lato client o viceversa.
Inoltre, sentirete le persone parlare di XML,
ancora un altro modo di codificare i dati mentre è in transito spedizione
tra il sito client e server.
Ora, e anche sentirai 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 rete.
E inoltre, sentirai le persone parlare di REST, non qualcosa
che ottieni troppo passando attraverso questo particolare corso.
REST o un trasferimento di stato rappresentativo.
Avrò una lezione più breve specificamente dedicata
a REST un po 'più tardi in questo modulo.
E nel mondo HTTP, sentirai persone parlare di GET,
PUT, POST e DELETE, e ti starai chiedendo,
cosa significano tutti?
Impariamo un po 'su questo 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 provoca quantità impreviste
di ritardi o quantità indeterminata di ritardo
mentre i dati vengono recuperati o caricati sul server dal lato client.
Quindi, il che significa che all'interno dell'applicazione client-server è
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 al 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 funzioni ancora in presenza di questi problemi.
Il protocollo Hypertext Transfer Protocol (
Hypertext Transfer Protocol), utilizzato per comunicare tra il client e il server,
ma si tratta di un protocollo di comunicazione del server client.
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 scambiati tra l'applicazione client,
che è un'applicazione angolare in questo caso, e un lato server.
Quindi, questo protocollo HTTP consente di recuperare documenti basati sull'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 quello 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 resto un po 'più tardi.
Come funziona il protocollo HTTP?
Nel protocollo HTTP, si sta inviando una richiesta 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,
cosa è che si desidera con il lato server per inviare all'utente
e questo è in genere un messaggio GET
se si desidera che i dati vengano scaricati dal sito server.
E specificherai anche con quale server stai comunicando.
Quando il server riceve la richiesta, il server
recupererà i dati dal suo archivio dati, in genere un database sul lato server,
quindi comprimerà questi dati in un appropriato quattro
indietro 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.
Di nuovo con applicazioni come angolare, ci si connette principalmente al server
e quindi si recuperano i 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 angolare all'interno del browser.
Così, come abbiamo visto in precedenza, l'applicazione HTTP richiede l'invio di messaggi
tra il client e il server.
Un messaggio di richiesta 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 i client inviano 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 un po 'più dettagli del messaggio di richiesta HTTP,
il messaggio di richiesta tipico nella riga di richiesta conterrà il metodo,
che è GET, PUT, PAUSE, DELETE
o alcuni degli altri verbi che hai visto in precedenza.
E poi, 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 chiediamo al server di mantenere
e indice.hmtl pagina dal lato server al lato client in modo
che possa essere reso 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, ancora una volta, in tre parti. Viene
memorizzata una riga di stato con alcune informazioni su come la richiesta è stata elaborata e ciò che viene inviato al client.
Le intestazioni conterranno ulteriori dettagli su ciò che è contenuto nel messaggio di risposta,
quindi seguiti 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 vedi qui, 200 nella riga di richiesta come codice di stato.
Ciò significa che la richiesta ha avuto esito positivo
e che il server è in grado di restituire i dati richiesti dal lato server.
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 HTML indice,
il corpo del messaggio conterrà il codice HTML
per la pagina HTML iniziale indice come illustrato in questo esempio.
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 punteggio di stato di 200,
il che significa che tutto è ok sul lato
server e il lato server restituisce correttamente i dati.
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 che significa che quando si tenta di creare un oggetto sul lato server,
è stato creato con successo o un 301, il che significa che tutto ciò che si sta richiedendo
è spostato in modo permanente in una nuova posizione
e che ci si trova nella nuova posizione di tale risorsa
verrà restituito al lato client.
400s e 500s in genere indicano che ci sono alcuni problemi sul lato server.
Un 404 è qualcosa che si incontra spesso quando si richiede
qualcosa che non esiste sul lato server.
Allo stesso modo, un 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 eXtensible Markup Language o JSON, la
notazione degli oggetti JavaScript per questo.
Ora, tipicamente in questo particolare corso ci occuperemo di dati
codificati principalmente in JSON.
La maggior parte delle applicazioni, le applicazioni lato client, incluse le applicazioni mobili,
in genere comunicano con il server
e il formato di scambio dati è JSON per impostazione predefinita nella maggior parte dei casi.
Questo è il motivo per cui passerò alcuni minuti a spiegarti su JSON.
La notazione dell'oggetto javascript, 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 dell'oggetto javascript, come suggerisce il nome, si
mappa molto facilmente in un oggetto javascript che si utilizza con uno qualsiasi dei codici javascript.
Quindi, convertire un oggetto javascript in notazione JSON,
e viceversa, è molto semplice.
Quella notazione JSON è una, ciò che chiamiamo,
come una notazione autodescrivibile e molto facile da capire.
Nel formato di notazione dell'oggetto javascript,
i dati sono strutturati in modo molto pulito e specificato.
Questo è strutturato come un insieme di coppie nome/valore,
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 con la 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 audio javascript, dattiloscritto è catturato nella tua applicazione angolare.
Con questo ho completato una rapida panoramica degli elementi essenziali per la rete.
Passeremo ora a ed esercitare dove ci sarà impostare un server rudimentale
che è stato servire alcuni dati che possiamo connettersi a dalla nostra applicazione angolare
e quindi scambiare i dati con un server.
Ora, svilupperemo un server completo in uno dei corsi successivi,
il codice nodo JS e corso di sviluppo lato server
che sarebbe venuto come ultimo corso in questa specializzazione.