1 00:00:01,670 --> 00:00:04,320 ‫Istruttore: Quindi, ora che sappiamo cos'è Express, 2 00:00:04,320 --> 00:00:07,550 ‫siamo quasi pronti per iniziare a creare la nostra API. 3 00:00:07,550 --> 00:00:08,890 ‫Ma prima 4 00:00:08,890 --> 00:00:12,300 ‫di farlo, devo parlare rapidamente delle API a 5 00:00:12,300 --> 00:00:13,910 ‫un livello superiore 6 00:00:13,910 --> 00:00:16,370 ‫e, cosa più importante, presentarti l'architettura 7 00:00:16,370 --> 00:00:19,640 ‫REST che è l'architettura API più utilizzata oggi. 8 00:00:19,640 --> 00:00:23,270 ‫In questo modo, sapremo effettivamente cosa stiamo costruendo. 9 00:00:23,270 --> 00:00:25,710 ‫Quindi è estremamente importante capire le cose in 10 00:00:25,710 --> 00:00:27,860 ‫questo video prima di andare avanti, 11 00:00:27,860 --> 00:00:30,580 ‫in modo che sappiamo effettivamente cosa stiamo costruendo 12 00:00:30,580 --> 00:00:32,603 ‫durante il resto del corso. 13 00:00:33,630 --> 00:00:34,890 ‫Prima di 14 00:00:34,890 --> 00:00:38,390 ‫tutto, API sta per Application Programming Interface e, a 15 00:00:38,390 --> 00:00:40,130 ‫un livello molto alto, 16 00:00:40,130 --> 00:00:43,150 ‫è fondamentalmente un software che può essere utilizzato 17 00:00:43,150 --> 00:00:45,270 ‫da un altro software per 18 00:00:45,270 --> 00:00:48,213 ‫consentire alle applicazioni di comunicare tra loro. 19 00:00:49,080 --> 00:00:51,420 ‫In realtà abbiamo già parlato di 20 00:00:51,420 --> 00:00:53,780 ‫API, in particolare di API Web, in 21 00:00:53,780 --> 00:00:56,300 ‫cui abbiamo semplicemente creato un'app che invia 22 00:00:56,300 --> 00:00:59,640 ‫dati a un client ogni volta che arriva una richiesta. 23 00:00:59,640 --> 00:01:02,530 ‫Immagina di avere la nostra app in esecuzione su un server 24 00:01:02,530 --> 00:01:04,060 ‫e di avere un client. 25 00:01:04,060 --> 00:01:08,020 ‫Quindi, in effetti, abbiamo effettivamente due software che 26 00:01:08,020 --> 00:01:10,250 ‫parlano tra loro, giusto? 27 00:01:10,250 --> 00:01:13,550 ‫E questo è il tipo di API che costruiremo in questo corso. 28 00:01:13,550 --> 00:01:17,470 ‫E immagino che sia il tipo di API più utilizzato in circolazione. 29 00:01:17,470 --> 00:01:21,970 ‫Ma in realtà, le API non vengono utilizzate solo per inviare dati e 30 00:01:21,970 --> 00:01:25,493 ‫non sono sempre correlate allo sviluppo web o a JavaScript. 31 00:01:26,400 --> 00:01:29,500 ‫L'applicazione in API può effettivamente significare 32 00:01:29,500 --> 00:01:32,710 ‫molte cose diverse purché il pezzo di 33 00:01:32,710 --> 00:01:35,050 ‫software sia relativamente autonomo. 34 00:01:35,050 --> 00:01:35,900 ‫Prendiamo ad 35 00:01:35,900 --> 00:01:38,870 ‫esempio il Node File System oi moduli HTTP. 36 00:01:38,870 --> 00:01:42,010 ‫Possiamo dire che sono piccoli pezzi di 37 00:01:42,010 --> 00:01:43,110 ‫software e 38 00:01:43,110 --> 00:01:46,970 ‫possiamo usarli, possiamo interagire con loro usando le loro API. 39 00:01:46,970 --> 00:01:47,803 ‫Ad 40 00:01:47,803 --> 00:01:51,150 ‫esempio, quando utilizziamo la funzione readfile dal modulo 41 00:01:51,150 --> 00:01:54,020 ‫FS, stiamo effettivamente utilizzando l'API FS. 42 00:01:54,020 --> 00:01:57,380 ‫Ed è per questo che a volte sentirai il termine API del nodo. 43 00:01:57,380 --> 00:02:01,090 ‫E questo di solito si riferisce semplicemente ai moduli del nodo 44 00:02:01,090 --> 00:02:02,920 ‫principale con cui possiamo interagire. 45 00:02:02,920 --> 00:02:05,670 ‫Oppure, quando effettuiamo la manipolazione del DOM nel 46 00:02:05,670 --> 00:02:08,650 ‫browser, non stiamo realmente utilizzando il linguaggio JavaScript stesso, 47 00:02:08,650 --> 00:02:12,440 ‫ma piuttosto l'API DOM che il browser ci espone, quindi ci 48 00:02:12,440 --> 00:02:14,280 ‫dà accesso ad esso. 49 00:02:14,280 --> 00:02:15,930 ‫O anche un altro esempio, 50 00:02:15,930 --> 00:02:19,080 ‫diciamo che creiamo una classe in qualsiasi linguaggio di 51 00:02:19,080 --> 00:02:21,940 ‫programmazione come Java e quindi aggiungiamo alcuni metodi 52 00:02:21,940 --> 00:02:23,420 ‫o proprietà pubblici. 53 00:02:23,420 --> 00:02:26,860 ‫Questi metodi saranno quindi l'API di ciascun oggetto 54 00:02:26,860 --> 00:02:29,450 ‫creato da quella classe perché diamo 55 00:02:29,450 --> 00:02:31,890 ‫ad altri software la possibilità di 56 00:02:31,890 --> 00:02:35,420 ‫interagire con il nostro software iniziale, gli oggetti, 57 00:02:35,420 --> 00:02:37,278 ‫in questo caso. 58 00:02:37,278 --> 00:02:40,810 ‫Vedete, l'API ha in realtà un significato più ampio rispetto alla 59 00:02:40,810 --> 00:02:42,810 ‫semplice creazione di API Web. 60 00:02:42,810 --> 00:02:47,420 ‫Bene? Ad ogni modo, un'API Web è ciò 61 00:02:47,420 --> 00:02:50,340 ‫che è più importante per noi nel contesto della nota. 62 00:02:50,340 --> 00:02:53,050 ‫Diamo ora un'occhiata all'architettura REST per 63 00:02:53,050 --> 00:02:54,203 ‫creare API. 64 00:02:55,820 --> 00:02:59,910 ‫REST, che sta per Representational States Transfer, è fondamentalmente un 65 00:02:59,910 --> 00:03:03,930 ‫modo di costruire API web in modo logico, rendendole 66 00:03:03,930 --> 00:03:06,060 ‫facili da consumare perché 67 00:03:06,060 --> 00:03:09,420 ‫ricorda, costruiamo un'API per noi stessi o per 68 00:03:09,420 --> 00:03:12,023 ‫gli altri da consumare, ok? 69 00:03:12,023 --> 00:03:15,640 ‫Vogliamo rendere il processo di utilizzo effettivo dell'API il più 70 00:03:15,640 --> 00:03:17,633 ‫agevole possibile per l'utente. 71 00:03:18,490 --> 00:03:20,830 ‫Ora, per creare API RESTful, 72 00:03:20,830 --> 00:03:24,180 ‫che significa API che seguono l'architettura REST, dobbiamo 73 00:03:24,180 --> 00:03:26,660 ‫solo seguire un paio di principi. 74 00:03:26,660 --> 00:03:31,240 ‫Innanzitutto, dobbiamo separare la nostra API in risorse logiche. 75 00:03:31,240 --> 00:03:33,860 ‫Queste risorse dovrebbero quindi essere esposte, 76 00:03:33,860 --> 00:03:35,900 ‫il che significa essere 77 00:03:35,900 --> 00:03:39,420 ‫rese disponibili utilizzando URL strutturati e basati sulle risorse. 78 00:03:39,420 --> 00:03:41,460 ‫Per eseguire diverse azioni 79 00:03:41,460 --> 00:03:44,677 ‫sui dati come leggere o creare o 80 00:03:44,677 --> 00:03:49,677 ‫eliminare dati, l'API deve utilizzare i metodi HTP corretti e non l'URL. 81 00:03:50,270 --> 00:03:53,210 ‫Ora, i dati che effettivamente inviamo al client 82 00:03:53,210 --> 00:03:55,420 ‫o che abbiamo ricevuto dal 83 00:03:55,420 --> 00:03:58,030 ‫client dovrebbero solitamente utilizzare il formato dati 84 00:03:58,030 --> 00:04:01,010 ‫JSON, a cui è applicato uno standard di formattazione. 85 00:04:01,010 --> 00:04:04,500 ‫Infine, un altro importante principio delle API 86 00:04:04,500 --> 00:04:07,560 ‫REST è che devono essere stateless. 87 00:04:07,560 --> 00:04:09,950 ‫Quindi questa è una panoramica molto ampia. 88 00:04:09,950 --> 00:04:12,030 ‫Iniziamo ora a parlare di 89 00:04:12,030 --> 00:04:15,310 ‫questi principi uno per uno partendo dalle risorse e 90 00:04:15,310 --> 00:04:17,810 ‫utilizzando l'API Nators che creeremo in questo 91 00:04:17,810 --> 00:04:19,803 ‫corso come esempio qui. 92 00:04:20,960 --> 00:04:24,910 ‫L'astrazione chiave delle informazioni in REST è una risorsa, 93 00:04:24,910 --> 00:04:27,450 ‫e quindi tutti i dati 94 00:04:27,450 --> 00:04:32,040 ‫che vogliamo condividere nell'API dovrebbero essere suddivisi in risorse logiche. 95 00:04:32,040 --> 00:04:34,350 ‫Ora, che cos'è in realtà una risorsa? 96 00:04:34,350 --> 00:04:36,380 ‫Bene, nel contesto di 97 00:04:36,380 --> 00:04:39,520 ‫REST, è un oggetto o una rappresentazione di 98 00:04:39,520 --> 00:04:42,020 ‫qualcosa a cui sono associati dei dati. 99 00:04:42,020 --> 00:04:42,853 ‫Ad 100 00:04:42,853 --> 00:04:45,570 ‫esempio, tour, o utenti, o recensioni 101 00:04:45,570 --> 00:04:48,020 ‫nel caso dell'esempio che stiamo seguendo. 102 00:04:48,020 --> 00:04:50,730 ‫Quindi, in pratica, qualsiasi informazione che può essere nominata 103 00:04:50,730 --> 00:04:53,040 ‫può essere una risorsa, va bene? 104 00:04:53,040 --> 00:04:56,050 ‫Deve essere solo un nome, però, non un verbo. 105 00:04:56,050 --> 00:04:57,690 ‫Ora, dobbiamo esporre, 106 00:04:57,690 --> 00:04:59,480 ‫il che significa rendere disponibili, 107 00:04:59,480 --> 00:05:02,520 ‫i dati utilizzando alcuni URL strutturati a cui 108 00:05:02,520 --> 00:05:04,890 ‫il client può inviare una richiesta. 109 00:05:04,890 --> 00:05:07,611 ‫Ad esempio, qualcosa del genere. 110 00:05:07,611 --> 00:05:10,740 ‫Questo intero indirizzo è chiamato URL 111 00:05:10,740 --> 00:05:14,323 ‫e questo /addNewTour è chiamato API Endpoint. 112 00:05:15,269 --> 00:05:17,840 ‫La nostra API avrà molti endpoint diversi 113 00:05:17,840 --> 00:05:20,560 ‫proprio come questi endpoint fittizi che ho 114 00:05:20,560 --> 00:05:23,730 ‫qui, ognuno dei quali invierà dati diversi al client 115 00:05:23,730 --> 00:05:26,150 ‫o eseguirà anche azioni diverse. 116 00:05:26,150 --> 00:05:28,440 ‫Ora, in realtà c'è qualcosa 117 00:05:28,440 --> 00:05:31,750 ‫di molto sbagliato in questi endpoint perché in realtà 118 00:05:31,750 --> 00:05:34,827 ‫non seguono la terza regola che dice che 119 00:05:34,827 --> 00:05:39,110 ‫dovremmo usare solo i metodi HTTP per eseguire azioni sui dati. 120 00:05:39,110 --> 00:05:42,360 ‫Quindi, gli endpoint dovrebbero contenere solo le nostre risorse e 121 00:05:42,360 --> 00:05:45,070 ‫non le azioni che possono essere eseguite 122 00:05:45,070 --> 00:05:48,313 ‫su di essi perché diventeranno rapidamente un incubo da mantenere. 123 00:05:49,644 --> 00:05:54,210 ‫Come dovremmo usare questi metodi HTTP in pratica? 124 00:05:54,210 --> 00:05:56,120 ‫Bene, vediamo come dovrebbero 125 00:05:56,120 --> 00:05:59,620 ‫effettivamente apparire questi endpoint a partire da /getTour. 126 00:05:59,620 --> 00:06:03,290 ‫Quindi questo endpoint /getTour serve per ottenere dati su un tour. 127 00:06:03,290 --> 00:06:06,240 ‫Quindi dovremmo semplicemente denominare l'endpoint /tours e inviare i 128 00:06:06,240 --> 00:06:08,740 ‫dati ogni volta che viene effettuata una richiesta 129 00:06:08,740 --> 00:06:10,430 ‫get a questo endpoint. 130 00:06:10,430 --> 00:06:11,650 ‫Quindi, in 131 00:06:11,650 --> 00:06:14,730 ‫altre parole, quando un client utilizza un metodo 132 00:06:14,730 --> 00:06:16,700 ‫GET HTTP per accedere all'endpoint. 133 00:06:16,700 --> 00:06:17,870 ‫E 134 00:06:17,870 --> 00:06:20,220 ‫proprio così, abbiamo solo risorse 135 00:06:20,220 --> 00:06:23,670 ‫nell'endpoint o nell'URL e nessun verbo perché il 136 00:06:23,670 --> 00:06:26,870 ‫verbo è ora nel metodo HTTP, giusto? 137 00:06:26,870 --> 00:06:27,703 ‫E a 138 00:06:27,703 --> 00:06:30,490 ‫proposito, è una pratica comune usare sempre il 139 00:06:30,490 --> 00:06:34,820 ‫nome della risorsa al plurale, motivo per cui ho /tours qui e non /tour. 140 00:06:34,820 --> 00:06:37,790 ‫Ora, la convenzione è che quando chiamiamo 141 00:06:37,790 --> 00:06:41,820 ‫quell'endpoint, riprendiamo tutti i tour che sono in un database, ok? 142 00:06:41,820 --> 00:06:44,820 ‫Ma se vogliamo il tour solo con una I. D. diciamo sette, aggiungiamo 143 00:06:44,820 --> 00:06:48,960 ‫quel sette dopo un'altra barra o in una query di ricerca. 144 00:06:48,960 --> 00:06:50,580 ‫Oppure potrebbe anche essere il nome di un tour al posto della I. D. o qualche altro identificatore univoco. 145 00:06:50,580 --> 00:06:53,490 ‫Il dettaglio non ha molta importanza a questo punto, va bene? 146 00:06:53,490 --> 00:06:55,410 ‫Più avanti, ti mostrerò quanto 147 00:06:55,410 --> 00:06:58,300 ‫sia facile implementare effettivamente questo tipo di logica con 148 00:06:58,300 --> 00:07:01,180 ‫Express perché è proprio qui che Express brilla davvero. 149 00:07:01,180 --> 00:07:03,410 ‫Il primo metodo o verbo 150 00:07:03,410 --> 00:07:06,733 ‫HTTP a cui possiamo rispondere è GET e viene 151 00:07:07,606 --> 00:07:10,460 ‫utilizzato per eseguire l'operazione di lettura sui dati. 152 00:07:10,460 --> 00:07:12,530 ‫Prossima fermata, se il cliente 153 00:07:12,530 --> 00:07:16,290 ‫vuole creare una nuova risorsa nel nostro database, in 154 00:07:16,290 --> 00:07:18,290 ‫questo esempio, un nuovo 155 00:07:18,290 --> 00:07:21,450 ‫tour, dovrebbe essere usato il metodo POST. 156 00:07:21,450 --> 00:07:23,200 ‫Quindi abbiamo appreso in precedenza che 157 00:07:23,200 --> 00:07:25,510 ‫una richiesta POST può essere utilizzata per 158 00:07:25,510 --> 00:07:28,490 ‫inviare dati al server, quindi ha senso utilizzare POST per 159 00:07:28,490 --> 00:07:30,230 ‫creare nuove risorse, giusto? 160 00:07:30,230 --> 00:07:32,270 ‫Ora, in questo caso, di solito no I. D. verrà inviato perché 161 00:07:32,270 --> 00:07:35,530 ‫il server dovrebbe rilevare automaticamente 162 00:07:35,530 --> 00:07:38,530 ‫l'I. D. per la nuova risorsa. 163 00:07:38,530 --> 00:07:40,860 ‫Ad ogni modo, ciò che è veramente importante notare qui è come il nome dell'endpoint sia esattamente 164 00:07:40,860 --> 00:07:42,948 ‫lo stesso nome di prima. 165 00:07:42,948 --> 00:07:46,090 ‫L'unica differenza è davvero 166 00:07:46,090 --> 00:07:50,289 ‫il metodo HTP utilizzato per la richiesta. 167 00:07:50,289 --> 00:07:53,870 ‫Se si accede all'endpoint /tours con GET, inviamo 168 00:07:53,870 --> 00:07:55,960 ‫i dati al client. 169 00:07:55,960 --> 00:07:59,410 ‫Ma se si accede allo stesso endpoint con POST, ci 170 00:07:59,410 --> 00:08:01,460 ‫aspettiamo che i dati arrivino 171 00:08:01,460 --> 00:08:04,060 ‫con una richiesta, in modo da poter 172 00:08:04,060 --> 00:08:06,550 ‫creare una nuova risorsa sul lato server. 173 00:08:06,550 --> 00:08:08,760 ‫Quindi questa è davvero la bellezza di usare solo metodi HTTP piuttosto che 174 00:08:08,760 --> 00:08:10,330 ‫fare confusione con i verbi nei nomi degli endpoint. 175 00:08:10,330 --> 00:08:14,460 ‫Ancora una volta, diventerebbe davvero ingestibile molto rapidamente. 176 00:08:14,460 --> 00:08:17,480 ‫Bene, poi dovrebbe esserci 177 00:08:17,480 --> 00:08:21,210 ‫anche la possibilità di aggiornare le risorse. 178 00:08:21,210 --> 00:08:23,620 ‫E per questo, è necessario 179 00:08:23,620 --> 00:08:26,390 ‫inviare una richiesta PUT o PATCH 180 00:08:26,390 --> 00:08:27,310 ‫all'endpoint. 181 00:08:27,310 --> 00:08:29,550 ‫La differenza tra loro è che 182 00:08:29,550 --> 00:08:31,550 ‫con PUT il client deve 183 00:08:31,550 --> 00:08:33,750 ‫inviare l'intero oggetto aggiornato, mentre con 184 00:08:33,750 --> 00:08:37,280 ‫PATCH deve inviare solo la parte dell'oggetto che è 185 00:08:37,280 --> 00:08:38,370 ‫stata modificata. 186 00:08:38,370 --> 00:08:40,967 ‫Ma entrambi hanno la capacità di 187 00:08:40,967 --> 00:08:43,060 ‫inviare dati al server. 188 00:08:43,060 --> 00:08:45,140 ‫Un po' come POST, in realtà, ma con un intento diverso. 189 00:08:45,140 --> 00:08:46,750 ‫Quindi POST serve 190 00:08:46,750 --> 00:08:50,750 ‫per creare una nuova risorsa, mentre PUT o PATCH vengono 191 00:08:50,750 --> 00:08:53,070 ‫utilizzati per aggiornare una risorsa esistente 192 00:08:53,070 --> 00:08:55,370 ‫e quindi fa la differenza. 193 00:08:55,370 --> 00:08:57,500 ‫E infine, per la risorsa 194 00:08:57,500 --> 00:08:59,660 ‫cucciolata, c'è il metodo DELETE HTTP. 195 00:08:59,660 --> 00:09:02,110 ‫Ancora una volta, l'I. D. o un altro identificatore univoco 196 00:09:02,110 --> 00:09:05,110 ‫della risorsa da eliminare dovrebbe essere parte 197 00:09:05,110 --> 00:09:08,010 ‫dell'URL. 198 00:09:08,010 --> 00:09:10,120 ‫Ora, di solito, per poter 199 00:09:10,120 --> 00:09:11,820 ‫effettivamente eseguire questo tipo 200 00:09:11,820 --> 00:09:14,560 ‫di richiesta, il client deve essere autenticato. 201 00:09:14,560 --> 00:09:16,610 ‫Quindi, in pratica, accedi alla tua app, ok? 202 00:09:16,610 --> 00:09:18,620 ‫Ma questo è, ovviamente, un argomento per molto più tardi. 203 00:09:18,620 --> 00:09:21,670 ‫Quindi questi sono i cinque metodi HTTP a 204 00:09:21,670 --> 00:09:24,349 ‫cui possiamo e dobbiamo rispondere durante la 205 00:09:24,349 --> 00:09:27,080 ‫creazione delle nostre API RESTful in modo 206 00:09:27,080 --> 00:09:29,320 ‫che il client possa eseguire 207 00:09:29,320 --> 00:09:31,570 ‫le quattro operazioni CRUD di base. 208 00:09:31,570 --> 00:09:33,270 ‫Quindi CRUD sta per Crea, Leggi, Aggiorna ed Elimina. 209 00:09:33,270 --> 00:09:36,290 ‫E vedrai questo termine tutto il 210 00:09:36,290 --> 00:09:40,730 ‫tempo relativo alle API e alle cose del database. 211 00:09:40,730 --> 00:09:42,590 ‫E vedi che questi metodi HTTP 212 00:09:42,590 --> 00:09:45,200 ‫si mappano abbastanza bene alle operazioni CRUD di base. 213 00:09:45,200 --> 00:09:47,490 ‫Ora, potrebbero esserci azioni 214 00:09:47,490 --> 00:09:51,330 ‫che non sono CRUD e, in tal caso, dobbiamo 215 00:09:51,330 --> 00:09:54,410 ‫solo essere creativi con i nostri input. 216 00:09:54,410 --> 00:09:55,460 ‫Ad esempio, un 217 00:09:55,460 --> 00:09:58,120 ‫login o un'operazione di ricerca, questi non sono 218 00:09:58,120 --> 00:09:58,953 ‫realmente correlati 219 00:09:58,953 --> 00:10:01,010 ‫a una particolare risorsa e non 220 00:10:01,010 --> 00:10:04,361 ‫sono nemmeno operazioni CRUD, ma possiamo comunque creare endpoint per loro. 221 00:10:04,361 --> 00:10:06,630 ‫Ad esempio, come /login o /search. 222 00:10:06,630 --> 00:10:09,240 ‫Ma parleremo più avanti di questi casi in pratica. 223 00:10:09,240 --> 00:10:12,530 ‫E solo per finire questa parte ora, 224 00:10:12,530 --> 00:10:16,350 ‫ricorda che avevamo altri due nomi di endpoint 225 00:10:16,350 --> 00:10:18,290 ‫folli nell'ultima diapositiva 226 00:10:18,290 --> 00:10:21,330 ‫che coinvolgevano due risorse contemporaneamente, giusto? 227 00:10:21,330 --> 00:10:23,870 ‫E anche questo non è un problema con REST. 228 00:10:23,870 --> 00:10:26,780 ‫Quindi, /getToursByUser può 229 00:10:26,780 --> 00:10:29,888 ‫essere semplicemente tradotto in /users/tours, 230 00:10:29,888 --> 00:10:33,810 ‫in questo caso, l'utente numero tre. 231 00:10:33,810 --> 00:10:36,210 ‫Quindi questo particolare endpoint qui potrebbe inviare 232 00:10:36,210 --> 00:10:38,440 ‫dati su tutti i tour che l'utente 233 00:10:38,440 --> 00:10:40,200 ‫numero tre ha prenotato. 234 00:10:40,200 --> 00:10:42,340 ‫Ha senso? 235 00:10:42,340 --> 00:10:44,580 ‫Oppure, in caso di eliminazione, potrebbe esserci 236 00:10:44,580 --> 00:10:45,519 ‫una richiesta 237 00:10:45,519 --> 00:10:47,470 ‫di eliminazione allo stesso o a 238 00:10:47,470 --> 00:10:50,170 ‫un endpoint molto simile, che richiede l'eliminazione del tour 239 00:10:50,170 --> 00:10:51,910 ‫numero nove dall'utente numero tre, ok? 240 00:10:51,910 --> 00:10:54,440 ‫Quindi ci sono davvero tantissime 241 00:10:54,440 --> 00:10:57,330 ‫possibilità di combinare risorse come questa. 242 00:10:57,330 --> 00:11:00,160 ‫Ma ovviamente non dobbiamo implementare tutte queste 243 00:11:00,160 --> 00:11:02,470 ‫combinazioni nella nostra API. 244 00:11:02,470 --> 00:11:04,260 ‫Implementiamo solo ciò che ha 245 00:11:04,260 --> 00:11:06,600 ‫senso nel caso della nostra applicazione e del 246 00:11:06,600 --> 00:11:08,400 ‫cliente che vuole utilizzare la nostra API. 247 00:11:08,400 --> 00:11:10,090 ‫Quindi, questo è il 248 00:11:10,090 --> 00:11:13,203 ‫modo in cui utilizziamo i metodi HTTP per creare URL 249 00:11:13,203 --> 00:11:17,480 ‫user-friendly e ben strutturati che siano facili e logici da utilizzare per il client. 250 00:11:17,480 --> 00:11:20,823 ‫Ora, per quanto riguarda i dati che il client 251 00:11:20,823 --> 00:11:24,145 ‫effettivamente riceve, o che il server riceve 252 00:11:24,145 --> 00:11:27,800 ‫dal client, di solito utilizziamo il formato dati JSON. 253 00:11:27,800 --> 00:11:30,610 ‫E quindi impariamo brevemente cos'è effettivamente JSON e 254 00:11:30,610 --> 00:11:33,203 ‫come formattare le nostre risposte API. 255 00:11:34,440 --> 00:11:37,400 ‫JSON è un formato di interscambio dati 256 00:11:37,400 --> 00:11:39,530 ‫molto leggero che è 257 00:11:39,530 --> 00:11:43,780 ‫molto utilizzato dalle API Web codificate in qualsiasi linguaggio di programmazione. 258 00:11:43,780 --> 00:11:46,220 ‫Quindi non è semplicemente correlato a un JavaScript. 259 00:11:46,220 --> 00:11:48,160 ‫Ed è così ampiamente utilizzato oggi perché 260 00:11:48,160 --> 00:11:50,740 ‫è davvero facile sia per gli umani che per 261 00:11:50,740 --> 00:11:52,620 ‫i computer capire e scrivere JSON. 262 00:11:52,620 --> 00:11:55,930 ‫Quindi probabilmente stai già notando che JSON assomiglia un po' 263 00:11:55,930 --> 00:11:57,990 ‫a un normale oggetto JavaScript, giusto? 264 00:11:57,990 --> 00:12:00,510 ‫Con tutte queste coppie chiave-valore. 265 00:12:00,510 --> 00:12:04,020 ‫Ci sono, tuttavia, alcune differenze e la più 266 00:12:04,020 --> 00:12:06,470 ‫importante è che tutte le chiavi 267 00:12:06,470 --> 00:12:08,320 ‫devono essere stringhe. 268 00:12:08,320 --> 00:12:10,960 ‫È anche molto tipico che i valori siano anche 269 00:12:10,960 --> 00:12:12,580 ‫stringhe, ma possono essere 270 00:12:12,580 --> 00:12:14,730 ‫altre cose come numeri, valori veri o 271 00:12:14,730 --> 00:12:17,440 ‫falsi, altri oggetti o persino array di altri valori. 272 00:12:17,440 --> 00:12:20,690 ‫È abbastanza semplice, in realtà. 273 00:12:20,690 --> 00:12:23,328 ‫E da questo esempio, puoi vedere come 274 00:12:23,328 --> 00:12:25,790 ‫potrebbe apparire un tipico JSON. 275 00:12:25,790 --> 00:12:27,070 ‫Diciamo che questo 276 00:12:27,070 --> 00:12:30,883 ‫è un dato che abbiamo nel nostro database per una richiesta 277 00:12:31,890 --> 00:12:35,290 ‫GET a questo URL, quindi il tour con I. D. di cinque. 278 00:12:35,290 --> 00:12:38,560 ‫Ora, potremmo rispedirlo in questo modo al client, ma 279 00:12:38,560 --> 00:12:41,440 ‫di solito 280 00:12:41,440 --> 00:12:44,300 ‫eseguiamo una semplice formattazione della risposta prima dell'invio. 281 00:12:44,300 --> 00:12:47,130 ‫Ci sono un paio di standard per questo e ne useremo 282 00:12:47,130 --> 00:12:48,620 ‫uno molto semplice chiamato Jsend. 283 00:12:48,620 --> 00:12:50,880 ‫Creiamo semplicemente un nuovo oggetto, quindi aggiungiamo 284 00:12:50,880 --> 00:12:54,570 ‫un messaggio di stato ad esso per informare il client se 285 00:12:54,570 --> 00:12:56,320 ‫la richiesta è stata 286 00:12:56,320 --> 00:12:58,310 ‫un successo, un errore o 287 00:12:58,310 --> 00:13:00,740 ‫un errore, quindi inseriamo i nostri dati 288 00:13:00,740 --> 00:13:03,350 ‫originali in un nuovo oggetto chiamato Dati, ok? 289 00:13:03,350 --> 00:13:05,390 ‫E possiamo svilupparlo anche 290 00:13:05,390 --> 00:13:08,510 ‫un po' oltre, ma questo è davvero il modo 291 00:13:08,510 --> 00:13:10,640 ‫più semplice di formattare con Jsend. 292 00:13:10,640 --> 00:13:12,020 ‫E comunque, avvolgere i dati 293 00:13:12,020 --> 00:13:14,250 ‫in un oggetto aggiuntivo come abbiamo fatto 294 00:13:14,250 --> 00:13:15,240 ‫qui si 295 00:13:15,240 --> 00:13:17,550 ‫chiama Enveloping ed è una pratica comune per 296 00:13:17,550 --> 00:13:19,860 ‫mitigare alcuni problemi di sicurezza e altri problemi. 297 00:13:19,860 --> 00:13:21,470 ‫Inoltre, esistono altri 298 00:13:21,470 --> 00:13:25,550 ‫standard per la formattazione delle risposte che puoi esaminare, come Jsend:API 299 00:13:25,550 --> 00:13:27,200 ‫o il protocollo JSON Odata. 300 00:13:27,200 --> 00:13:30,330 ‫Va bene, e infine, 301 00:13:30,330 --> 00:13:34,333 ‫un'API RESTful dovrebbe sempre essere senza stato. 302 00:13:35,800 --> 00:13:37,470 ‫Quindi, cosa significa in realtà apolide? 303 00:13:37,470 --> 00:13:40,720 ‫Bene, in un'API RESTful senza stato, tutto 304 00:13:40,720 --> 00:13:43,170 ‫lo stato viene gestito 305 00:13:43,170 --> 00:13:45,960 ‫sul client e non sul server. 306 00:13:45,960 --> 00:13:48,410 ‫E lo stato si riferisce semplicemente a un dato 307 00:13:48,410 --> 00:13:50,120 ‫nell'applicazione che potrebbe cambiare nel tempo. 308 00:13:50,120 --> 00:13:52,910 ‫Ad esempio, se un determinato utente è connesso 309 00:13:52,910 --> 00:13:55,750 ‫o su una pagina con un elenco con 310 00:13:55,750 --> 00:13:56,583 ‫più 311 00:13:56,583 --> 00:13:58,720 ‫pagine, qual è la pagina corrente. 312 00:13:58,720 --> 00:14:02,230 ‫Ora il fatto che lo stato debba essere gestito 313 00:14:02,230 --> 00:14:04,150 ‫sul client significa che 314 00:14:04,150 --> 00:14:06,170 ‫ogni richiesta deve contenere tutte le 315 00:14:06,170 --> 00:14:09,910 ‫informazioni necessarie per elaborare una determinata richiesta sul server, va bene? 316 00:14:09,910 --> 00:14:12,710 ‫Ha senso? 317 00:14:12,710 --> 00:14:15,780 ‫Quindi, il server non dovrebbe mai 318 00:14:15,780 --> 00:14:17,170 ‫ricordare la 319 00:14:17,170 --> 00:14:21,030 ‫richiesta precedente per elaborare la richiesta corrente. 320 00:14:21,030 --> 00:14:24,010 ‫Prendiamo come esempio l'elenco con più pagine. 321 00:14:24,010 --> 00:14:25,906 ‫E diciamo che è ricorrente 322 00:14:25,906 --> 00:14:29,670 ‫a pagina cinque e vogliamo andare avanti a pagina sei. 323 00:14:29,670 --> 00:14:32,980 ‫Quindi potremmo avere un semplice endpoint chiamato 324 00:14:32,980 --> 00:14:36,006 ‫/tours/nextPage e inviargli una richiesta, giusto? 325 00:14:36,006 --> 00:14:39,710 ‫Ma il server dovrebbe quindi capire qual è la pagina 326 00:14:40,650 --> 00:14:43,400 ‫corrente e in base a ciò inviare 327 00:14:43,400 --> 00:14:45,610 ‫la pagina successiva al client. 328 00:14:45,610 --> 00:14:48,450 ‫In altre parole, il server dovrebbe 329 00:14:48,450 --> 00:14:50,496 ‫ricordare la richiesta precedente. 330 00:14:50,496 --> 00:14:51,730 ‫Dovrebbe gestire il 331 00:14:51,730 --> 00:14:54,950 ‫lato server di stato e questo è esattamente ciò 332 00:14:54,950 --> 00:14:57,640 ‫che vogliamo evitare nelle API RESTful, ok? 333 00:14:57,640 --> 00:15:00,260 ‫Invece, in questo caso, dovremmo creare 334 00:15:00,260 --> 00:15:03,120 ‫un /tours/page endpoint e incollarvi il 335 00:15:03,120 --> 00:15:04,630 ‫numero sei 336 00:15:04,630 --> 00:15:07,550 ‫per richiedere la pagina numero sei. 337 00:15:07,550 --> 00:15:09,410 ‫In questo modo, dichiareremmo sul client 338 00:15:09,410 --> 00:15:11,850 ‫perché su un client sapremmo già che siamo 339 00:15:11,850 --> 00:15:14,340 ‫a pagina cinque e quindi tutto ciò che 340 00:15:14,340 --> 00:15:15,410 ‫dovevamo fare 341 00:15:15,410 --> 00:15:18,320 ‫era aggiungerne uno e quindi richiedere la pagina numero sei. 342 00:15:18,320 --> 00:15:20,750 ‫Quindi il server non deve ricordare 343 00:15:20,750 --> 00:15:22,750 ‫nulla in questo caso. 344 00:15:22,750 --> 00:15:23,920 ‫Tutto quello che deve fare è 345 00:15:23,920 --> 00:15:25,840 ‫inviare i dati per la pagina numero sei come richiesto. 346 00:15:25,840 --> 00:15:27,940 ‫E a proposito, l'apolidia e 347 00:15:27,940 --> 00:15:30,840 ‫la stateness, che è l'opposto, sono concetti 348 00:15:30,840 --> 00:15:33,891 ‫molto importanti nell'informatica e nella progettazione delle 349 00:15:33,891 --> 00:15:35,760 ‫applicazioni in generale. 350 00:15:35,760 --> 00:15:38,560 ‫Quindi, è una buona idea avere effettivamente una certa comprensione di 351 00:15:38,560 --> 00:15:40,800 ‫cosa sia un'API senza stato e come funziona. 352 00:15:40,800 --> 00:15:44,070 ‫Comunque, questa è stata una conferenza enorme, 353 00:15:44,070 --> 00:15:47,331 ‫ma anche una delle più importanti. 354 00:15:47,331 --> 00:15:50,280 ‫Non posso sottolinearlo abbastanza e penso che 355 00:15:50,280 --> 00:15:52,670 ‫tu possa vederlo, giusto? 356 00:15:52,670 --> 00:15:55,700 ‫Comunque, torniamo finalmente al nostro codice.