‫Istruttore: Quindi, ora che sappiamo cos'è Express,
‫siamo quasi pronti per iniziare a creare la nostra API.
‫Ma prima
‫di farlo, devo parlare rapidamente delle API a
‫un livello superiore
‫e, cosa più importante, presentarti l'architettura
‫REST che è l'architettura API più utilizzata oggi.
‫In questo modo, sapremo effettivamente cosa stiamo costruendo.
‫Quindi è estremamente importante capire le cose in
‫questo video prima di andare avanti,
‫in modo che sappiamo effettivamente cosa stiamo costruendo
‫durante il resto del corso.
‫Prima di
‫tutto, API sta per Application Programming Interface e, a
‫un livello molto alto,
‫è fondamentalmente un software che può essere utilizzato
‫da un altro software per
‫consentire alle applicazioni di comunicare tra loro.
‫In realtà abbiamo già parlato di
‫API, in particolare di API Web, in
‫cui abbiamo semplicemente creato un'app che invia
‫dati a un client ogni volta che arriva una richiesta.
‫Immagina di avere la nostra app in esecuzione su un server
‫e di avere un client.
‫Quindi, in effetti, abbiamo effettivamente due software che
‫parlano tra loro, giusto?
‫E questo è il tipo di API che costruiremo in questo corso.
‫E immagino che sia il tipo di API più utilizzato in circolazione.
‫Ma in realtà, le API non vengono utilizzate solo per inviare dati e
‫non sono sempre correlate allo sviluppo web o a JavaScript.
‫L'applicazione in API può effettivamente significare
‫molte cose diverse purché il pezzo di
‫software sia relativamente autonomo.
‫Prendiamo ad
‫esempio il Node File System oi moduli HTTP.
‫Possiamo dire che sono piccoli pezzi di
‫software e
‫possiamo usarli, possiamo interagire con loro usando le loro API.
‫Ad
‫esempio, quando utilizziamo la funzione readfile dal modulo
‫FS, stiamo effettivamente utilizzando l'API FS.
‫Ed è per questo che a volte sentirai il termine API del nodo.
‫E questo di solito si riferisce semplicemente ai moduli del nodo
‫principale con cui possiamo interagire.
‫Oppure, quando effettuiamo la manipolazione del DOM nel
‫browser, non stiamo realmente utilizzando il linguaggio JavaScript stesso,
‫ma piuttosto l'API DOM che il browser ci espone, quindi ci
‫dà accesso ad esso.
‫O anche un altro esempio,
‫diciamo che creiamo una classe in qualsiasi linguaggio di
‫programmazione come Java e quindi aggiungiamo alcuni metodi
‫o proprietà pubblici.
‫Questi metodi saranno quindi l'API di ciascun oggetto
‫creato da quella classe perché diamo
‫ad altri software la possibilità di
‫interagire con il nostro software iniziale, gli oggetti,
‫in questo caso.
‫Vedete, l'API ha in realtà un significato più ampio rispetto alla
‫semplice creazione di API Web.
‫Bene? Ad ogni modo, un'API Web è ciò
‫che è più importante per noi nel contesto della nota.
‫Diamo ora un'occhiata all'architettura REST per
‫creare API.
‫REST, che sta per Representational States Transfer, è fondamentalmente un
‫modo di costruire API web in modo logico, rendendole
‫facili da consumare perché
‫ricorda, costruiamo un'API per noi stessi o per
‫gli altri da consumare, ok?
‫Vogliamo rendere il processo di utilizzo effettivo dell'API il più
‫agevole possibile per l'utente.
‫Ora, per creare API RESTful,
‫che significa API che seguono l'architettura REST, dobbiamo
‫solo seguire un paio di principi.
‫Innanzitutto, dobbiamo separare la nostra API in risorse logiche.
‫Queste risorse dovrebbero quindi essere esposte,
‫il che significa essere
‫rese disponibili utilizzando URL strutturati e basati sulle risorse.
‫Per eseguire diverse azioni
‫sui dati come leggere o creare o
‫eliminare dati, l'API deve utilizzare i metodi HTP corretti e non l'URL.
‫Ora, i dati che effettivamente inviamo al client
‫o che abbiamo ricevuto dal
‫client dovrebbero solitamente utilizzare il formato dati
‫JSON, a cui è applicato uno standard di formattazione.
‫Infine, un altro importante principio delle API
‫REST è che devono essere stateless.
‫Quindi questa è una panoramica molto ampia.
‫Iniziamo ora a parlare di
‫questi principi uno per uno partendo dalle risorse e
‫utilizzando l'API Nators che creeremo in questo
‫corso come esempio qui.
‫L'astrazione chiave delle informazioni in REST è una risorsa,
‫e quindi tutti i dati
‫che vogliamo condividere nell'API dovrebbero essere suddivisi in risorse logiche.
‫Ora, che cos'è in realtà una risorsa?
‫Bene, nel contesto di
‫REST, è un oggetto o una rappresentazione di
‫qualcosa a cui sono associati dei dati.
‫Ad
‫esempio, tour, o utenti, o recensioni
‫nel caso dell'esempio che stiamo seguendo.
‫Quindi, in pratica, qualsiasi informazione che può essere nominata
‫può essere una risorsa, va bene?
‫Deve essere solo un nome, però, non un verbo.
‫Ora, dobbiamo esporre,
‫il che significa rendere disponibili,
‫i dati utilizzando alcuni URL strutturati a cui
‫il client può inviare una richiesta.
‫Ad esempio, qualcosa del genere.
‫Questo intero indirizzo è chiamato URL
‫e questo /addNewTour è chiamato API Endpoint.
‫La nostra API avrà molti endpoint diversi
‫proprio come questi endpoint fittizi che ho
‫qui, ognuno dei quali invierà dati diversi al client
‫o eseguirà anche azioni diverse.
‫Ora, in realtà c'è qualcosa
‫di molto sbagliato in questi endpoint perché in realtà
‫non seguono la terza regola che dice che
‫dovremmo usare solo i metodi HTTP per eseguire azioni sui dati.
‫Quindi, gli endpoint dovrebbero contenere solo le nostre risorse e
‫non le azioni che possono essere eseguite
‫su di essi perché diventeranno rapidamente un incubo da mantenere.
‫Come dovremmo usare questi metodi HTTP in pratica?
‫Bene, vediamo come dovrebbero
‫effettivamente apparire questi endpoint a partire da /getTour.
‫Quindi questo endpoint /getTour serve per ottenere dati su un tour.
‫Quindi dovremmo semplicemente denominare l'endpoint /tours e inviare i
‫dati ogni volta che viene effettuata una richiesta
‫get a questo endpoint.
‫Quindi, in
‫altre parole, quando un client utilizza un metodo
‫GET HTTP per accedere all'endpoint.
‫E
‫proprio così, abbiamo solo risorse
‫nell'endpoint o nell'URL e nessun verbo perché il
‫verbo è ora nel metodo HTTP, giusto?
‫E a
‫proposito, è una pratica comune usare sempre il
‫nome della risorsa al plurale, motivo per cui ho /tours qui e non /tour.
‫Ora, la convenzione è che quando chiamiamo
‫quell'endpoint, riprendiamo tutti i tour che sono in un database, ok?
‫Ma se vogliamo il tour solo con una I. D. diciamo sette, aggiungiamo
‫quel sette dopo un'altra barra o in una query di ricerca.
‫Oppure potrebbe anche essere il nome di un tour al posto della I. D. o qualche altro identificatore univoco.
‫Il dettaglio non ha molta importanza a questo punto, va bene?
‫Più avanti, ti mostrerò quanto
‫sia facile implementare effettivamente questo tipo di logica con
‫Express perché è proprio qui che Express brilla davvero.
‫Il primo metodo o verbo
‫HTTP a cui possiamo rispondere è GET e viene
‫utilizzato per eseguire l'operazione di lettura sui dati.
‫Prossima fermata, se il cliente
‫vuole creare una nuova risorsa nel nostro database, in
‫questo esempio, un nuovo
‫tour, dovrebbe essere usato il metodo POST.
‫Quindi abbiamo appreso in precedenza che
‫una richiesta POST può essere utilizzata per
‫inviare dati al server, quindi ha senso utilizzare POST per
‫creare nuove risorse, giusto?
‫Ora, in questo caso, di solito no I. D. verrà inviato perché
‫il server dovrebbe rilevare automaticamente
‫l'I. D. per la nuova risorsa.
‫Ad ogni modo, ciò che è veramente importante notare qui è come il nome dell'endpoint sia esattamente
‫lo stesso nome di prima.
‫L'unica differenza è davvero
‫il metodo HTP utilizzato per la richiesta.
‫Se si accede all'endpoint /tours con GET, inviamo
‫i dati al client.
‫Ma se si accede allo stesso endpoint con POST, ci
‫aspettiamo che i dati arrivino
‫con una richiesta, in modo da poter
‫creare una nuova risorsa sul lato server.
‫Quindi questa è davvero la bellezza di usare solo metodi HTTP piuttosto che
‫fare confusione con i verbi nei nomi degli endpoint.
‫Ancora una volta, diventerebbe davvero ingestibile molto rapidamente.
‫Bene, poi dovrebbe esserci
‫anche la possibilità di aggiornare le risorse.
‫E per questo, è necessario
‫inviare una richiesta PUT o PATCH
‫all'endpoint.
‫La differenza tra loro è che
‫con PUT il client deve
‫inviare l'intero oggetto aggiornato, mentre con
‫PATCH deve inviare solo la parte dell'oggetto che è
‫stata modificata.
‫Ma entrambi hanno la capacità di
‫inviare dati al server.
‫Un po' come POST, in realtà, ma con un intento diverso.
‫Quindi POST serve
‫per creare una nuova risorsa, mentre PUT o PATCH vengono
‫utilizzati per aggiornare una risorsa esistente
‫e quindi fa la differenza.
‫E infine, per la risorsa
‫cucciolata, c'è il metodo DELETE HTTP.
‫Ancora una volta, l'I. D. o un altro identificatore univoco
‫della risorsa da eliminare dovrebbe essere parte
‫dell'URL.
‫Ora, di solito, per poter
‫effettivamente eseguire questo tipo
‫di richiesta, il client deve essere autenticato.
‫Quindi, in pratica, accedi alla tua app, ok?
‫Ma questo è, ovviamente, un argomento per molto più tardi.
‫Quindi questi sono i cinque metodi HTTP a
‫cui possiamo e dobbiamo rispondere durante la
‫creazione delle nostre API RESTful in modo
‫che il client possa eseguire
‫le quattro operazioni CRUD di base.
‫Quindi CRUD sta per Crea, Leggi, Aggiorna ed Elimina.
‫E vedrai questo termine tutto il
‫tempo relativo alle API e alle cose del database.
‫E vedi che questi metodi HTTP
‫si mappano abbastanza bene alle operazioni CRUD di base.
‫Ora, potrebbero esserci azioni
‫che non sono CRUD e, in tal caso, dobbiamo
‫solo essere creativi con i nostri input.
‫Ad esempio, un
‫login o un'operazione di ricerca, questi non sono
‫realmente correlati
‫a una particolare risorsa e non
‫sono nemmeno operazioni CRUD, ma possiamo comunque creare endpoint per loro.
‫Ad esempio, come /login o /search.
‫Ma parleremo più avanti di questi casi in pratica.
‫E solo per finire questa parte ora,
‫ricorda che avevamo altri due nomi di endpoint
‫folli nell'ultima diapositiva
‫che coinvolgevano due risorse contemporaneamente, giusto?
‫E anche questo non è un problema con REST.
‫Quindi, /getToursByUser può
‫essere semplicemente tradotto in /users/tours,
‫in questo caso, l'utente numero tre.
‫Quindi questo particolare endpoint qui potrebbe inviare
‫dati su tutti i tour che l'utente
‫numero tre ha prenotato.
‫Ha senso?
‫Oppure, in caso di eliminazione, potrebbe esserci
‫una richiesta
‫di eliminazione allo stesso o a
‫un endpoint molto simile, che richiede l'eliminazione del tour
‫numero nove dall'utente numero tre, ok?
‫Quindi ci sono davvero tantissime
‫possibilità di combinare risorse come questa.
‫Ma ovviamente non dobbiamo implementare tutte queste
‫combinazioni nella nostra API.
‫Implementiamo solo ciò che ha
‫senso nel caso della nostra applicazione e del
‫cliente che vuole utilizzare la nostra API.
‫Quindi, questo è il
‫modo in cui utilizziamo i metodi HTTP per creare URL
‫user-friendly e ben strutturati che siano facili e logici da utilizzare per il client.
‫Ora, per quanto riguarda i dati che il client
‫effettivamente riceve, o che il server riceve
‫dal client, di solito utilizziamo il formato dati JSON.
‫E quindi impariamo brevemente cos'è effettivamente JSON e
‫come formattare le nostre risposte API.
‫JSON è un formato di interscambio dati
‫molto leggero che è
‫molto utilizzato dalle API Web codificate in qualsiasi linguaggio di programmazione.
‫Quindi non è semplicemente correlato a un JavaScript.
‫Ed è così ampiamente utilizzato oggi perché
‫è davvero facile sia per gli umani che per
‫i computer capire e scrivere JSON.
‫Quindi probabilmente stai già notando che JSON assomiglia un po'
‫a un normale oggetto JavaScript, giusto?
‫Con tutte queste coppie chiave-valore.
‫Ci sono, tuttavia, alcune differenze e la più
‫importante è che tutte le chiavi
‫devono essere stringhe.
‫È anche molto tipico che i valori siano anche
‫stringhe, ma possono essere
‫altre cose come numeri, valori veri o
‫falsi, altri oggetti o persino array di altri valori.
‫È abbastanza semplice, in realtà.
‫E da questo esempio, puoi vedere come
‫potrebbe apparire un tipico JSON.
‫Diciamo che questo
‫è un dato che abbiamo nel nostro database per una richiesta
‫GET a questo URL, quindi il tour con I. D. di cinque.
‫Ora, potremmo rispedirlo in questo modo al client, ma
‫di solito
‫eseguiamo una semplice formattazione della risposta prima dell'invio.
‫Ci sono un paio di standard per questo e ne useremo
‫uno molto semplice chiamato Jsend.
‫Creiamo semplicemente un nuovo oggetto, quindi aggiungiamo
‫un messaggio di stato ad esso per informare il client se
‫la richiesta è stata
‫un successo, un errore o
‫un errore, quindi inseriamo i nostri dati
‫originali in un nuovo oggetto chiamato Dati, ok?
‫E possiamo svilupparlo anche
‫un po' oltre, ma questo è davvero il modo
‫più semplice di formattare con Jsend.
‫E comunque, avvolgere i dati
‫in un oggetto aggiuntivo come abbiamo fatto
‫qui si
‫chiama Enveloping ed è una pratica comune per
‫mitigare alcuni problemi di sicurezza e altri problemi.
‫Inoltre, esistono altri
‫standard per la formattazione delle risposte che puoi esaminare, come Jsend:API
‫o il protocollo JSON Odata.
‫Va bene, e infine,
‫un'API RESTful dovrebbe sempre essere senza stato.
‫Quindi, cosa significa in realtà apolide?
‫Bene, in un'API RESTful senza stato, tutto
‫lo stato viene gestito
‫sul client e non sul server.
‫E lo stato si riferisce semplicemente a un dato
‫nell'applicazione che potrebbe cambiare nel tempo.
‫Ad esempio, se un determinato utente è connesso
‫o su una pagina con un elenco con
‫più
‫pagine, qual è la pagina corrente.
‫Ora il fatto che lo stato debba essere gestito
‫sul client significa che
‫ogni richiesta deve contenere tutte le
‫informazioni necessarie per elaborare una determinata richiesta sul server, va bene?
‫Ha senso?
‫Quindi, il server non dovrebbe mai
‫ricordare la
‫richiesta precedente per elaborare la richiesta corrente.
‫Prendiamo come esempio l'elenco con più pagine.
‫E diciamo che è ricorrente
‫a pagina cinque e vogliamo andare avanti a pagina sei.
‫Quindi potremmo avere un semplice endpoint chiamato
‫/tours/nextPage e inviargli una richiesta, giusto?
‫Ma il server dovrebbe quindi capire qual è la pagina
‫corrente e in base a ciò inviare
‫la pagina successiva al client.
‫In altre parole, il server dovrebbe
‫ricordare la richiesta precedente.
‫Dovrebbe gestire il
‫lato server di stato e questo è esattamente ciò
‫che vogliamo evitare nelle API RESTful, ok?
‫Invece, in questo caso, dovremmo creare
‫un /tours/page endpoint e incollarvi il
‫numero sei
‫per richiedere la pagina numero sei.
‫In questo modo, dichiareremmo sul client
‫perché su un client sapremmo già che siamo
‫a pagina cinque e quindi tutto ciò che
‫dovevamo fare
‫era aggiungerne uno e quindi richiedere la pagina numero sei.
‫Quindi il server non deve ricordare
‫nulla in questo caso.
‫Tutto quello che deve fare è
‫inviare i dati per la pagina numero sei come richiesto.
‫E a proposito, l'apolidia e
‫la stateness, che è l'opposto, sono concetti
‫molto importanti nell'informatica e nella progettazione delle
‫applicazioni in generale.
‫Quindi, è una buona idea avere effettivamente una certa comprensione di
‫cosa sia un'API senza stato e come funziona.
‫Comunque, questa è stata una conferenza enorme,
‫ma anche una delle più importanti.
‫Non posso sottolinearlo abbastanza e penso che
‫tu possa vederlo, giusto?
‫Comunque, torniamo finalmente al nostro codice.