Lascia che ti dia un breve riposo. Ti ho portato lì.
Quello che volevo dire è che vi do
una breve panoramica del trasferimento di Stato rappresentativo.
Cos' è esattamente REST?
Come facciamo a utilizzarlo nella nostra applicazione React,
e come facciamo a fare uso di questo per comunicare con il server?
In che modo un server supporta l'API REST
e come accediamo all'API REST dalla nostra applicazione React?
Parliamone un po' di più in questa lezione.
Sono sicuro che abbiate sentito il termine servizi web essere 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 che sono 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 collegate a Internet per essere in grado di
comunicare tra loro a
livello di applicazione per applicazioni basate sul Web utilizzando 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 che vengono utilizzati per supportare i servizi Web sono SOAP.
I servizi Web basati su Simple Object Access Protocol che utilizza
il linguaggio di descrizione dei servizi Web per
specificare il modo in cui i due endpoint comunicano tra loro.
In genere SOAP si basa sull'utilizzo di XML come
formato per i messaggi scambiati tra i due endpoint.
Rappresentational State Transfer o REST utilizza anche standard web,
ma lo scambio di dati tra i due endpoint potrebbe essere XML o
utilizzando sempre più JSON come formato.
Il modo REST di interoperabilità è più semplice rispetto a SOAP e, quindi,
REST ha trovato una distribuzione molto più ampia nel mondo dei servizi web.
In genere, la comunicazione client-server è
facilitata utilizzando REST in cui il server supporta un'API REST e
il client può quindi richiamare gli endpoint API REST
al fine di ottenere informazioni o caricare informazioni sul server.
Ancora una volta, ho menzionato la parola invocare gli endpoint dell'API REST,
quindi questi sono alcuni termini che ho usato.
Cerchiamo di chiarire alcuni di questi nelle prossime diapositive.
Rappresentational State Transfer è uno stile di architettura software
appositamente progettato per ipermedia 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 di riposo.
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 non ricorda
nulla di più sulla 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 (Uniform Resource Locators - URL).
In quarto luogo, il formato per lo scambio di dati è in genere JSON
o XML o entrambi possono essere supportati utilizzando REST.
Una delle motivazioni per Roy che suggerisce REST come un modo per supportare i servizi web
è che cattura tutte le cose che sono buone sul
World Wide Web e che hanno reso il World Wide Web di successo.
Utilizzo di Uniform Resource
Indicators o Uniform Resource Locator (URL) che consentono di
indirizzare le risorse specificandole come URL.
Il secondo, essendo un protocollo che vive sopra il protocollo HTTP.
HTTP ha già trovato un'ampia distribuzione in Internet.
In terzo luogo, il ciclo di risposta della richiesta che HTTP è noto per.
Quindi invii una richiesta,
il server riceve la tua richiesta, elabora
la richiesta, invia la risposta alla richiesta
e il client riceve la risposta,
agisce su di essa e può generare ulteriori richieste.
Quindi, questo approccio del ciclo di risposta della richiesta è molto
ben stabilito con HTTP e il World Wide Web.
Ora, il protocollo HTTP come abbiamo visto in precedenza,
useremo tutti i vari verbi che HTTP fornisce.
in particolare, GET,
PUT, POST e DELETE per poter
specificare le operazioni da eseguire sulle risorse memorizzate sul lato server.
Ad esempio, se si esegue una richiesta HTTP GET,
si sta chiedendo al server di restituire la risorsa.
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 DELETE,
si sta chiedendo al server di eliminare
la risorsa identificata dal particolare URL.
Inoltre, cerca di preservare Idempotenza.
Alcune operazioni, quando vengono eseguite anche ripetutamente,
non causeranno alcun cambiamento di stato.
Alcune altre operazioni, se le fai successivamente,
potrebbero causare un cambiamento di stato.
Quindi è necessario stare attenti a quali operazioni possono essere ripetute
senza conseguenze dannose e che devono essere eseguite con molta attenzione.
Nel mondo REST si sente spesso persone parlare di nomi, verbi e rappresentazioni.
Ora, spiegheremo ognuno di questi in modo un po 'più dettagliato nelle prossime diapositive.
I nomi si riferiscono specificamente alle risorse e queste risorse sono
generalmente identificate dai relativi URL e non sono vincolate. I
verbi sono vincoli e questi specificano le azioni da
fare sulle risorse e le rappresentazioni come vediamo.
Quando le informazioni devono essere trasmesse
dal server al client o dal client al server,
come si codificano le informazioni.
In genere, utilizzando JSON o XML. La
risorsa è l'astrazione chiave su cui REST funziona.
Quindi, le informazioni vengono astratte sotto forma di una risorsa e la risorsa
viene identificata specificandola utilizzando un URL.
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 pezzo di informazione a cui un cliente può essere interessato,
può essere identificato come una risorsa.
È anche possibile gestire le risorse come raccolta di
risorse che il server può inviare al client.
Qui viene illustrato un esempio di come nominare le risorse.
Quindi usiamo URI per identificare la fonte.
Una rapida lettura di queste specifiche o degli URI qui
ti permetterà facilmente di capire a cosa ci riferiamo usando questi URI.
Quindi, per esempio, qualcosa che termina con i piatti/,
si assume automaticamente che questo si riferisce a una raccolta di piatti.
Ma piatti/123 per esempio,
potrebbe significare piatto numero 123 in questo caso e così via.
Quindi, è molto facile da salvare ed è possibile specificare
una raccolta di risorse ed essere in grado di
identificarle come una raccolta e quindi scaricarle come una raccolta oppure è possibile
identificare una singola risorsa e dire che si desidera quella particolare risorsa.
Ora, queste risorse possono essere organizzate in una gerarchia della specifica di questo URI.
Quindi, mentre attraversi il percorso,
passi dal più generale al più specifico della risorsa.
Questa struttura di directory consente di identificare
molto facilmente le risorse utilizzate o fornite dal lato server.
La seconda parte dell'API REST sono i verbi.
In particolare, siamo interessati ai quattro verbi di HTTP GET,
PUT, POST e DELETE.
In questo caso, questi verbi saranno mappati in azioni che
vogliamo essere eseguite sulla risorsa, sul lato server.
Un GET significa che si desidera eseguire un'operazione di lettura sulla risorsa.
Quindi, il che significa che un client che invia una richiesta GET indica
al server che desidera ottenere una rappresentazione
di quella risorsa dal lato server al lato client.
Un POST significa che si desidera creare
una nuova risorsa e quindi specificare i dettagli della risorsa
nella rappresentazione che viene utilizzata per
specificare la risorsa e quindi inviare tali informazioni sul lato server, in
modo che il server creerà tale risorsa per conto dell'utente.
Un PUT sarebbe la modifica delle risorse e
un DELETE come ci si aspetterebbe è la cancellazione delle risorse.
Quindi, come puoi vedere, i quattro verbi;
GET, POST, PUT e DELETE,
sono mappati nelle quattro operazioni CRUD che è possibile
eseguire su un database che memorizza queste risorse sul lato server, le
operazioni READ, CREATE, UPDATE e DELETE.
Elaborando ulteriormente, HTTP GET è un modo per specificare che si
desidera che le informazioni o
la rappresentazione della risorsa vengano restituite al client dal lato server.
Pertanto, quando si emette una richiesta GET a un endpoint API REST,
si richiede una raccolta di risorse rappresentate dall'
URI o una risorsa specifica identificata dall'ID di quella particolare risorsa,
specificata all'interno dell'URL.
Quindi, come si vede in questo esempio,
se si dice, piatti/452,
si intende dire che il piatto numero 452 con
l'ID 452 dovrebbe essere restituito al lato client.
Allo stesso modo, l'operazione POST come abbiamo visto viene utilizzata per creare la risorsa.
Pertanto, quando si crea la risorsa,
il contenuto della descrizione della risorsa sarebbe sotto forma di una rappresentazione JSON o
una rappresentazione XML e che verrà incluso
nel corpo del messaggio di richiesta inviato al lato server.
Quindi, un'operazione POST prevede una rappresentazione
della risorsa in formato JSON o XML nel corpo del messaggio di richiesta.
Quando il server riceve tale messaggio di richiesta,
il server crea tale risorsa sul lato server e quindi restituisce
una conformazione o un errore per indicare che la creazione della risorsa non è riuscita.
Allo stesso modo, un'operazione PUT viene utilizzata 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 del 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.
Un' operazione DELETE come ci si aspetterebbe elimina la risorsa esistente.
Ora, in questo caso particolare,
ovviamente un'operazione DELETE sarebbe idempotente 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,
tranne che il server risponderà con un errore che indica che la risorsa non esiste.
Ma, tuttavia, DELETE è un esempio di un'operazione idempotente in questo caso.
Allo stesso modo, l'operazione GET è anche un'operazione idempotente perché
non apporta alcuna modifica alla risorsa sul lato server.
POST e PUT ovviamente modificheranno la risorsa sul lato server,
creeranno una nuova risorsa o modificheranno una risorsa esistente sul lato server.
Naturalmente, le rappresentazioni,
come ho sottolineato, i
due formati comuni per la rappresentazione sono JSON o 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 ha bisogno di tenere traccia dello stato dei client,
non sarà scalabile.
Pertanto, per un'implementazione scalabile del lato server,
normalmente si utilizza un server senza stato sul lato server.
Pertanto, ogni richiesta che il client invia al server verrà
trattata come una richiesta indipendente e
non rifletterà sulle richieste precedenti
che sono già state gestite dal server da quel particolare client.
Quindi, è responsabilità del cliente monitorare il proprio stato,
sia sotto forma di utilizzo dei cookie o utilizzando un database lato client,
qualunque sia il mezzo che sia adatto.
Ora, questo approccio in cui il client tiene traccia del proprio stato è
molto più scalabile perché ogni singolo client
sarà responsabile del monitoraggio del proprio stato.
Questo è dove l'installazione MVC lato client ci aiuta a questo proposito.
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.