Lascia che ti dia un breve riposo.
Ti ho beccato lì!
Quello che volevo dire era:
lasciatemi dare una breve panoramica sul trasferimento dello stato rappresentativo.
Cos' è esattamente il riposo?
Come facciamo a usarlo nella nostra applicazione angolare e
come facciamo a utilizzare questo per comunicare con il server?
In che modo un server supporta l'API REST e
come accediamo all'API REST dalla nostra applicazione Angular?
Parliamone un po' di più in questa lezione.
In questa particolare lezione, ti darò una breve panoramica di REST.
Sono sicuro che il termine Web Services viene menzionato
molto spesso nel mondo IT.
Che cosa sono esattamente i servizi web?
I servizi Web sono un modo di progettare sistemi per supportare l'interoperabilità tra
i sistemi collegati su una rete, come Internet come vediamo oggi.
Questo è ciò che definiamo un'architettura orientata ai servizi.
Ora, ciò significa che si fornisce un modo standardizzato per due macchine
che sono collegate a Internet per essere in grado di comunicare tra loro.
Il loro livello di layout dell'applicazione per
le applicazioni di database che utilizzano standard aperti.
Ora, ho usato un sacco di gergo lì.
Proviamo a suddividerli e
capire un po 'di ciascuno di questi in questa lezione.
Due approcci comuni utilizzati per supportare i servizi Web sono SOAP,
i semplici servizi Web basati sul protocollo di accesso agli oggetti,
che utilizza il linguaggio di descrizione dei servizi Web per
specificare il modo in cui i due endpoint comunicano tra loro.
E in genere, soap si basa sull'utilizzo di XML come
formato per i messaggi scambiati tra i due endpoint.
Il trasferimento dello stato di presentazione o resto utilizza anche gli standard web, ma lo scambio
di dati tra i due endpoint potrebbe essere XML o sempre più.
Utilizzo di JSON come formato.
Il modo REST di interoperabilità è più semplice rispetto a SOAP e
quindi REST ha trovato una distribuzione molto più ampia nei servizi web rimasti.
In genere, la comunicazione del server client è facilitata utilizzando REST
in cui il server supporta l'API REST e il client può quindi richiamare i loro
endpoint API REST al fine di ottenere informazioni o caricare informazioni sul server.
Ancora una volta, ho menzionato la parola, invocare quel punto finale dell'API REST.
Quindi questi sono alcuni termini che ho usato.
Cerchiamo di chiarire alcuni di questi nelle prossime diapositive.
Il trasferimento dello stato rappresentativo è uno stile di architettura software
appositamente progettato per gli hypermedia distribuiti sul World Wide Web.
Ora questo è stato introdotto per la prima volta da Roy Fielding nella sua tesi di dottorato.
Ora, questa è una di quelle tesi di dottorato che in realtà ha prodotto
qualcosa di utile per il mondo.
Quindi questo ha trovato ancora un sacco di trazione nel mondo dei servizi web.
Si tratta di una raccolta di principi di rete che illustrano come le risorse possono essere
rese disponibili sui server e a queste risorse è possibile accedere
dai client identificando le risorse utilizzando gli endpoint API REST.
All' interno del trasferimento dello stato rappresentativo ci sono quattro principi di progettazione di base.
Innanzitutto, REST è costruito sul protocollo HTTP.
Quindi utilizza tutti i metodi HTTP che abbiamo già visto nella lezione precedente.
In secondo luogo, REST è progettato per essere senza stato, il che significa che il server non memorizza
alcuna informazione sullo stato dopo che la comunicazione è stata completata.
Quindi, quando un server riceve la richiesta, il server risponde e
poi, dopo, non ricorda nulla di più su quella
conversazione tra il client e il server.
In terzo luogo, il modo REST di fornire risorse consiste nell'
esporre una struttura di directory come URL di localizzatori di risorse uniformi.
E quarto il loro formato per lo scambio di dati è in genere JSON o
XML, o entrambi che possono essere supportati utilizzando REST.
Una delle motivazioni per l'aumento suggerendo REST come un modo per supportare
i servizi web è che cattura tutto ciò che è buono di tutto il World Wide Web.
E questo ha reso il Word Wide Web di successo.
L' uso di Uniform Resource Indicators o Uniform Resource Locator, URL,
che consentono di indirizzare le risorse specificandole come URL,
il secondo è un protocollo che si basa sul protocollo HTTP.
HTTP ha già trovato un'ampia distribuzione in Internet.
In terzo luogo, il ciclo di risposta della richiesta che HTTP è ben noto per.
Quindi si invia una richiesta, il server riceve la richiesta, elabora la richiesta,
invia la risposta alla richiesta e quel client riceve la risposta,
agisce su di essa e può generare ulteriori richieste.
Quindi, questo approccio del ciclo di risposta richiesta è molto ben stabilito con HTTP
e il protocollo Web HTTP mondiale come abbiamo visto in precedenza,
useremo tutti i vari verbi che HTTP fornisce.
In particolare, il cancello messo post cancella.
Per essere in grado di specificare le operazioni da eseguire
sulle risorse che sono memorizzate sul lato server.
Ad esempio, se si esegue una richiesta HTTP GET, si sta chiedendo
al server di restituire l'origine.
Se si esegue una richiesta POST, si sta chiedendo al server di creare una nuova risorsa.
Se si esegue una richiesta PUT, si sta chiedendo al server di aggiornare
una risorsa esistente e se si emette una richiesta di eliminazione si sta chiedendo
al server di eliminare la risorsa identificata da quel particolare URL.
Inoltre, cerca di preservare l'idempotenza.
Alcune operazioni quando vengono eseguite
Anche ripetutamente non causerà alcun cambiamento di stato.
Alcune altre operazioni, se le fai successivamente,
potrebbero causare un cambiamento di stato.
Quindi è necessario fare attenzione a quali operazioni possono essere ripetute
senza conseguenze dannose.
E che devono essere fatti con molta attenzione.
Nel mondo REST, spesso si sente parlare di nomi,
verbi e rappresentazioni.
Ora chiariremo ognuno di questi in modo un po 'più dettagliato nelle prossime diapositive.
I nomi, in particolare, sono pieni di risorse e
queste risorse sono solitamente identificate dai loro URL e queste non sono vincolate. I
verbi sono vincolati e queste azioni specificate da fare sulle risorse.
E le presentazioni come vediamo quando le informazioni devono essere trasmesse
dal server al client o
dal client al server, come codificare le informazioni.
In genere utilizzando JSON o XML. La
risorsa è l'astrazione chiave che REST funziona in modo
che le informazioni vengano astratte nella risorsa.
E la risorsa viene identificata specificandola utilizzando un URI.
Quindi qualsiasi informazione che può essere incapsulata e
resa disponibile può essere identificata come una risorsa.
Un pezzo di informazioni come il tempo attuale a Hong Kong potrebbe essere una risorsa,
un'immagine potrebbe essere una risorsa.
Un' informazione sul prezzo delle azioni potrebbe essere una risorsa, e così via.
Quindi qualunque cosa tu definisca come un'informazione a cui un cliente potrebbe essere
interessato, può essere identificata come una risorsa.
È anche possibile gestire le risorse come raccolta di risorse
che il server può inviare a quel client.
Qui viene illustrato un esempio di come nominare le risorse.
Quindi usiamo URI per identificare la fonte.
Una rapida lettura delle specifiche o degli URL qui
vi permetterà facilmente di capire a cosa ci riferiamo utilizzando questi URL.
Quindi, per esempio, qualcosa che termina con i piatti/,
si assume automaticamente che questo si riferisce a una raccolta di piatti.
Come piatti/123 per esempio,
potrebbe significare piatto numero 123, in questo caso e così via.
Quindi è molto facile dire che è possibile specificare una raccolta di risorse, ed
essere in grado di identificarle come una raccolta, e quindi scaricarle come una raccolta. In
alternativa, è possibile identificare una singola risorsa e
dire che si desidera quella particolare risorsa.
Ora queste risorse possono essere organizzate in una gerarchia
che specifica di questo URI.
Quindi, mentre attraversi il percorso,
passi dal più generale al più specifico di quella risorsa.
Questa struttura di directory consente di identificare le risorse
fornite dal sito del servizio in modo molto semplice.
La seconda parte dell'API REST sono le parole.
In particolare siamo interessati ai 4 verbi di HTTP da ottenere,
mettere, pubblicare ed eliminare.
In questo caso questi verbi saranno pisolino in azioni che
vogliamo essere eseguite sulla risorsa sul lato server.
GetT significa che si desidera eseguire un'operazione di lettura sulla risorsa, il
che significa che un client che invia una richiesta get indica al server
che desidera ottenere la presentazione dell'origine dati dal sito server al sito client.
POST significa che vuoi creare una nuova risorsa e poi lo farai.
Specificare i dettagli della risorsa nella rappresentazione, ma viene utilizzato per
specificare la risorsa.
Quindi inviare le informazioni sul lato server, in modo
che il server creerà la risorsa per conto dell'utente.
Un PUT sarebbe la modifica delle risorse e l'
eliminazione, come ci si aspetterebbe, è la cancellazione delle fonti.
Quindi, come puoi vedere i quattro verbi get, post, put ed
delete sono mappati nelle quattro operazioni CRUD che puoi eseguire
su un database che memorizza queste risorse sul lato server.
Le operazioni di lettura, creazione, aggiornamento ed eliminazione.
Elaborando ulteriormente, HTTP GET è un modo di specificare.
Che si desidera che le informazioni o la loro presentazione della risorsa vengano
restituite al client dal sito server.
Quindi, quando si emette una richiesta GET a un endpoint API REST.
Stai chiedendo una raccolta di risorse che sono presentate da
Uri o una risorsa specifica che è identificata dall'ID di
quelle particolari risorse specificate all'interno dell'URL in modo che vedi in questo esempio,
se piatti/452, intendi dire quel piatto numero 452,
con il id 452 deve essere restituito al lato client.
Allo stesso modo, l'operazione post, come abbiamo visto, viene utilizzata per creare la risorsa.
Quindi, quando si crea la risorsa, il contenuto della descrizione
della risorsa sarebbe sotto forma di una rappresentazione JSON o una rappresentazione XML e che sarebbe
incluso nel corpo del messaggio di richiesta inviato al lato server.
Quindi un'operazione post si aspetta una rappresentazione
della risorsa in formato JSON o XML nel corpo del messaggio di richiesta.
E il server riceve tale messaggio di richiesta, il server crea tale
risorsa sul lato server e quindi restituisce una conferma o
un errore per indicare che la creazione della risorsa non è riuscita.
Allo stesso modo mette l'operazione facile da usare per aggiornare una risorsa.
Quando si esegue un'operazione PUT su una risorsa sul lato server, è possibile inviare indietro
la modifica specificando solo la modifica parziale
che si desidera applicare sulla particolare risorsa nel corpo del messaggio di risposta.
Oppure è possibile inviare la rappresentazione completa della risorsa
nel corpo del messaggio, a seconda della disposizione tra il client e
il server, il server si aspetta che le informazioni vengano
trasmesse nel corpo del messaggio di richiesta.
L' operazione DELETE come ci si aspetterebbe elimina la risorsa esistente.
Ora, in questo caso particolare, ovviamente, un'operazione di eliminazione sarebbe perché
se si tenta di eliminare una risorsa e la risorsa esiste, verrà eliminata.
Se si sta tentando di eliminare una risorsa non esistente,
non causerà ulteriori modifiche sul lato server Ad eccezione del fatto
che il server risponderà con un errore che dice che la risorsa non esiste.
Ma tuttavia, è un esempio di un'operazione in questo caso.
Analogamente, l'operazione get funzionerà anche perché non
apporta alcuna modifica alla risorsa sul sito server.
L' input post ovviamente modificherà la risorsa sul lato server.
È necessario creare una nuova risorsa o
modificare la risorsa esistente sul lato server e, naturalmente, presentazioni di dati.
Come ho sottolineato, i due fallback comuni per la
rappresentazione sono JSON XML, l'ultima parte
che dobbiamo sottolineare è che il lato server dovrebbe essere completamente senza stato. Il
che significa che il lato server non tiene traccia dello stato del client.
Perché, se il server deve tenere traccia dello stato del client, non sarà scalabile.
Quindi, per un'implementazione scalabile del lato server,
normalmente si utilizza un server senza stato sul lato server.
Quindi, se la richiesta dei client inviati al server verrà trattata come
una richiesta indipendente e non rifletterà sulle
richieste precedenti che sono già state gestite dal server dal particolare client.
Quindi è responsabilità del cliente rintracciare il proprio stato.
O sotto forma di utilizzo di cookie o utilizzo di un database del sito client.
Qualunque sia il mezzo che sia adatto.
Ora, questo approccio in cui il client tiene traccia del proprio stato è molto più scalabile,
perché il tuo client sarà responsabile del monitoraggio del proprio.
E questo è dove l'installazione MVC lato client ci aiuta a questo proposito.
E infine non abbiamo ancora finito con REST, vedremo più di
REST negli esercizi che seguono in questa particolare lezione.
E poi,
vedremo ulteriori dettagli sull'utilizzo REST nel resto di questo corso.
[ MUSIC]