1
00:00:03,200 --> 00:00:09,035
Lascia che ti dia un breve riposo. Ti ho portato lì.

2
00:00:09,035 --> 00:00:11,535
Quello che volevo dire è che vi do

3
00:00:11,535 --> 00:00:16,420
una breve panoramica del trasferimento di Stato rappresentativo.

4
00:00:16,420 --> 00:00:18,460
Cos' è esattamente REST?

5
00:00:18,460 --> 00:00:22,670
Come facciamo a utilizzarlo nella nostra applicazione React,

6
00:00:22,670 --> 00:00:26,130
e come facciamo a fare uso di questo per comunicare con il server?

7
00:00:26,130 --> 00:00:29,455
In che modo un server supporta l'API REST

8
00:00:29,455 --> 00:00:34,615
e come accediamo all'API REST dalla nostra applicazione React?

9
00:00:34,615 --> 00:00:39,230
Parliamone un po' di più in questa lezione.

10
00:00:39,230 --> 00:00:47,680
Sono sicuro che abbiate sentito il termine servizi web essere menzionato molto spesso nel mondo IT.

11
00:00:47,680 --> 00:00:49,895
Che cosa sono esattamente i servizi web?

12
00:00:49,895 --> 00:00:55,520
I servizi Web sono un modo di progettare sistemi per supportare l'interoperabilità

13
00:00:55,520 --> 00:01:01,745
tra i sistemi che sono collegati su una rete come Internet come vediamo oggi.

14
00:01:01,745 --> 00:01:05,504
Questo è ciò che definiamo un'architettura orientata ai servizi.

15
00:01:05,504 --> 00:01:09,170
Ora, ciò significa che si fornisce

16
00:01:09,170 --> 00:01:14,870
un modo standardizzato per due macchine collegate a Internet per essere in grado di

17
00:01:14,870 --> 00:01:17,720
comunicare tra loro a

18
00:01:17,720 --> 00:01:24,660
livello di applicazione per applicazioni basate sul Web utilizzando standard aperti.

19
00:01:24,660 --> 00:01:29,175
Ora, ho usato un sacco di gergo lì.

20
00:01:29,175 --> 00:01:32,000
Proviamo a suddividerli e capire

21
00:01:32,000 --> 00:01:36,195
un po 'di ciascuno di questi in questa lezione.

22
00:01:36,195 --> 00:01:43,390
Due approcci comuni che vengono utilizzati per supportare i servizi Web sono SOAP.

23
00:01:43,390 --> 00:01:49,550
I servizi Web basati su Simple Object Access Protocol che utilizza

24
00:01:49,550 --> 00:01:52,805
il linguaggio di descrizione dei servizi Web per

25
00:01:52,805 --> 00:01:57,080
specificare il modo in cui i due endpoint comunicano tra loro.

26
00:01:57,080 --> 00:02:01,700
In genere SOAP si basa sull'utilizzo di XML come

27
00:02:01,700 --> 00:02:07,340
formato per i messaggi scambiati tra i due endpoint.

28
00:02:07,340 --> 00:02:12,975
Rappresentational State Transfer o REST utilizza anche standard web,

29
00:02:12,975 --> 00:02:17,240
ma lo scambio di dati tra i due endpoint potrebbe essere XML o

30
00:02:17,240 --> 00:02:22,385
utilizzando sempre più JSON come formato.

31
00:02:22,385 --> 00:02:29,705
Il modo REST di interoperabilità è più semplice rispetto a SOAP e, quindi,

32
00:02:29,705 --> 00:02:37,650
REST ha trovato una distribuzione molto più ampia nel mondo dei servizi web.

33
00:02:37,650 --> 00:02:41,215
In genere, la comunicazione client-server è

34
00:02:41,215 --> 00:02:45,830
facilitata utilizzando REST in cui il server supporta un'API REST e

35
00:02:45,830 --> 00:02:49,960
il client può quindi richiamare gli endpoint API REST

36
00:02:49,960 --> 00:02:54,595
al fine di ottenere informazioni o caricare informazioni sul server.

37
00:02:54,595 --> 00:02:59,885
Ancora una volta, ho menzionato la parola invocare gli endpoint dell'API REST,

38
00:02:59,885 --> 00:03:03,210
quindi questi sono alcuni termini che ho usato.

39
00:03:03,210 --> 00:03:07,385
Cerchiamo di chiarire alcuni di questi nelle prossime diapositive.

40
00:03:07,385 --> 00:03:12,590
Rappresentational State Transfer è uno stile di architettura software

41
00:03:12,590 --> 00:03:18,200
appositamente progettato per ipermedia distribuiti sul World Wide Web.

42
00:03:18,200 --> 00:03:24,604
Ora questo è stato introdotto per la prima volta da Roy Fielding nella sua tesi di dottorato.

43
00:03:24,604 --> 00:03:26,990
Ora questa è una di quelle tesi di dottorato

44
00:03:26,990 --> 00:03:29,660
che in realtà ha prodotto qualcosa di utile per il mondo.

45
00:03:29,660 --> 00:03:38,690
Quindi questo ha trovato ancora un sacco di trazione nel mondo dei servizi web.

46
00:03:38,690 --> 00:03:42,800
Si tratta di una raccolta di principi di rete che illustrano come

47
00:03:42,800 --> 00:03:47,300
le risorse possono essere rese disponibili sui server

48
00:03:47,300 --> 00:03:50,950
e a queste risorse è possibile accedere

49
00:03:50,950 --> 00:03:56,285
dai client identificando le risorse utilizzando gli endpoint API di riposo.

50
00:03:56,285 --> 00:03:58,855
All' interno del trasferimento dello stato rappresentativo,

51
00:03:58,855 --> 00:04:01,050
ci sono quattro principi di progettazione di base.

52
00:04:01,050 --> 00:04:05,375
Innanzitutto, REST è costruito sul protocollo HTTP,

53
00:04:05,375 --> 00:04:11,365
quindi utilizza tutti i metodi HTTP che abbiamo già visto nella lezione precedente.

54
00:04:11,365 --> 00:04:15,045
In secondo luogo, REST è progettato per essere senza stato,

55
00:04:15,045 --> 00:04:17,930
il che significa che il server non memorizza alcuna informazione

56
00:04:17,930 --> 00:04:21,450
sullo stato dopo che la comunicazione è stata completata.

57
00:04:21,450 --> 00:04:25,615
Quindi, quando un server riceve la richiesta, il server risponde,

58
00:04:25,615 --> 00:04:29,110
e poi non ricorda

59
00:04:29,110 --> 00:04:33,340
nulla di più sulla conversazione tra il client e il server.

60
00:04:33,340 --> 00:04:38,635
In terzo luogo, il modo REST di fornire risorse consiste nell'

61
00:04:38,635 --> 00:04:44,945
esporre una struttura di directory come URL (Uniform Resource Locators - URL).

62
00:04:44,945 --> 00:04:50,230
In quarto luogo, il formato per lo scambio di dati è in genere JSON

63
00:04:50,230 --> 00:04:56,145
o XML o entrambi possono essere supportati utilizzando REST.

64
00:04:56,145 --> 00:05:03,350
Una delle motivazioni per Roy che suggerisce REST come un modo per supportare i servizi web

65
00:05:03,350 --> 00:05:06,620
è che cattura tutte le cose che sono buone sul

66
00:05:06,620 --> 00:05:10,880
World Wide Web e che hanno reso il World Wide Web di successo.

67
00:05:10,880 --> 00:05:14,040
Utilizzo di Uniform Resource

68
00:05:14,040 --> 00:05:18,320
Indicators o Uniform Resource Locator (URL) che consentono di

69
00:05:18,320 --> 00:05:23,170
indirizzare le risorse specificandole come URL.

70
00:05:23,170 --> 00:05:29,390
Il secondo, essendo un protocollo che vive sopra il protocollo HTTP.

71
00:05:29,390 --> 00:05:34,600
HTTP ha già trovato un'ampia distribuzione in Internet.

72
00:05:34,600 --> 00:05:40,135
In terzo luogo, il ciclo di risposta della richiesta che HTTP è noto per.

73
00:05:40,135 --> 00:05:42,420
Quindi invii una richiesta,

74
00:05:42,420 --> 00:05:45,775
il server riceve la tua richiesta, elabora

75
00:05:45,775 --> 00:05:49,530
la richiesta, invia la risposta alla richiesta

76
00:05:49,530 --> 00:05:51,830
e il client riceve la risposta,

77
00:05:51,830 --> 00:05:54,765
agisce su di essa e può generare ulteriori richieste.

78
00:05:54,765 --> 00:05:58,580
Quindi, questo approccio del ciclo di risposta della richiesta è molto

79
00:05:58,580 --> 00:06:03,115
ben stabilito con HTTP e il World Wide Web.

80
00:06:03,115 --> 00:06:08,505
Ora, il protocollo HTTP come abbiamo visto in precedenza,

81
00:06:08,505 --> 00:06:13,650
useremo tutti i vari verbi che HTTP fornisce.

82
00:06:13,650 --> 00:06:15,520
in particolare, GET,

83
00:06:15,520 --> 00:06:18,635
PUT, POST e DELETE per poter

84
00:06:18,635 --> 00:06:23,480
specificare le operazioni da eseguire sulle risorse memorizzate sul lato server.

85
00:06:23,480 --> 00:06:27,470
Ad esempio, se si esegue una richiesta HTTP GET,

86
00:06:27,470 --> 00:06:30,125
si sta chiedendo al server di restituire la risorsa.

87
00:06:30,125 --> 00:06:32,415
Se si esegue una richiesta POST,

88
00:06:32,415 --> 00:06:35,415
si sta chiedendo al server di creare una nuova risorsa.

89
00:06:35,415 --> 00:06:36,670
Se si esegue una richiesta PUT,

90
00:06:36,670 --> 00:06:39,650
si sta chiedendo al server di aggiornare una risorsa esistente.

91
00:06:39,650 --> 00:06:42,170
E se si emette una richiesta DELETE,

92
00:06:42,170 --> 00:06:45,020
si sta chiedendo al server di eliminare

93
00:06:45,020 --> 00:06:48,070
la risorsa identificata dal particolare URL.

94
00:06:48,070 --> 00:06:51,735
Inoltre, cerca di preservare Idempotenza.

95
00:06:51,735 --> 00:06:56,165
Alcune operazioni, quando vengono eseguite anche ripetutamente,

96
00:06:56,165 --> 00:06:58,225
non causeranno alcun cambiamento di stato.

97
00:06:58,225 --> 00:07:02,085
Alcune altre operazioni, se le fai successivamente,

98
00:07:02,085 --> 00:07:05,170
potrebbero causare un cambiamento di stato.

99
00:07:05,170 --> 00:07:08,780
Quindi è necessario stare attenti a quali operazioni possono essere ripetute

100
00:07:08,780 --> 00:07:14,395
senza conseguenze dannose e che devono essere eseguite con molta attenzione.

101
00:07:14,395 --> 00:07:21,864
Nel mondo REST si sente spesso persone parlare di nomi, verbi e rappresentazioni.

102
00:07:21,864 --> 00:07:27,875
Ora, spiegheremo ognuno di questi in modo un po 'più dettagliato nelle prossime diapositive.

103
00:07:27,875 --> 00:07:31,760
I nomi si riferiscono specificamente alle risorse e queste risorse sono

104
00:07:31,760 --> 00:07:36,320
generalmente identificate dai relativi URL e non sono vincolate. I

105
00:07:36,320 --> 00:07:40,700
verbi sono vincoli e questi specificano le azioni da

106
00:07:40,700 --> 00:07:45,010
fare sulle risorse e le rappresentazioni come vediamo.

107
00:07:45,010 --> 00:07:47,285
Quando le informazioni devono essere trasmesse

108
00:07:47,285 --> 00:07:49,910
dal server al client o dal client al server,

109
00:07:49,910 --> 00:07:51,855
come si codificano le informazioni.

110
00:07:51,855 --> 00:07:56,520
In genere, utilizzando JSON o XML. La

111
00:07:56,520 --> 00:08:01,895
risorsa è l'astrazione chiave su cui REST funziona.

112
00:08:01,895 --> 00:08:06,810
Quindi, le informazioni vengono astratte sotto forma di una risorsa e la risorsa

113
00:08:06,810 --> 00:08:12,475
viene identificata specificandola utilizzando un URL.

114
00:08:12,475 --> 00:08:18,395
Quindi, qualsiasi informazione che può essere incapsulata e resa disponibile,

115
00:08:18,395 --> 00:08:20,720
può essere identificata come una risorsa.

116
00:08:20,720 --> 00:08:26,980
Un pezzo di informazioni come il tempo attuale a Hong Kong potrebbe essere una risorsa,

117
00:08:26,980 --> 00:08:29,345
un'immagine potrebbe essere una risorsa,

118
00:08:29,345 --> 00:08:33,985
un'informazione sul prezzo delle azioni potrebbe essere una risorsa e così via.

119
00:08:33,985 --> 00:08:38,920
Quindi, qualunque cosa tu definisca come un pezzo di informazione a cui un cliente può essere interessato,

120
00:08:38,920 --> 00:08:41,430
può essere identificato come una risorsa.

121
00:08:41,430 --> 00:08:44,045
È anche possibile gestire le risorse come raccolta di

122
00:08:44,045 --> 00:08:48,740
risorse che il server può inviare al client.

123
00:08:48,740 --> 00:08:54,145
Qui viene illustrato un esempio di come nominare le risorse.

124
00:08:54,145 --> 00:08:57,740
Quindi usiamo URI per identificare la fonte.

125
00:08:57,740 --> 00:09:03,355
Una rapida lettura di queste specifiche o degli URI qui

126
00:09:03,355 --> 00:09:10,460
ti permetterà facilmente di capire a cosa ci riferiamo usando questi URI.

127
00:09:10,460 --> 00:09:14,420
Quindi, per esempio, qualcosa che termina con i piatti/,

128
00:09:14,420 --> 00:09:19,315
si assume automaticamente che questo si riferisce a una raccolta di piatti.

129
00:09:19,315 --> 00:09:22,795
Ma piatti/123 per esempio,

130
00:09:22,795 --> 00:09:28,250
potrebbe significare piatto numero 123 in questo caso e così via.

131
00:09:28,250 --> 00:09:31,320
Quindi, è molto facile da salvare ed è possibile specificare

132
00:09:31,320 --> 00:09:34,650
una raccolta di risorse ed essere in grado di

133
00:09:34,650 --> 00:09:38,815
identificarle come una raccolta e quindi scaricarle come una raccolta oppure è possibile

134
00:09:38,815 --> 00:09:43,965
identificare una singola risorsa e dire che si desidera quella particolare risorsa.

135
00:09:43,965 --> 00:09:50,395
Ora, queste risorse possono essere organizzate in una gerarchia della specifica di questo URI.

136
00:09:50,395 --> 00:09:52,740
Quindi, mentre attraversi il percorso,

137
00:09:52,740 --> 00:09:58,325
passi dal più generale al più specifico della risorsa.

138
00:09:58,325 --> 00:10:02,110
Questa struttura di directory consente di identificare

139
00:10:02,110 --> 00:10:07,780
molto facilmente le risorse utilizzate o fornite dal lato server.

140
00:10:07,780 --> 00:10:11,585
La seconda parte dell'API REST sono i verbi.

141
00:10:11,585 --> 00:10:16,760
In particolare, siamo interessati ai quattro verbi di HTTP GET,

142
00:10:16,760 --> 00:10:19,140
PUT, POST e DELETE.

143
00:10:19,140 --> 00:10:24,410
In questo caso, questi verbi saranno mappati in azioni che

144
00:10:24,410 --> 00:10:29,755
vogliamo essere eseguite sulla risorsa, sul lato server.

145
00:10:29,755 --> 00:10:34,170
Un GET significa che si desidera eseguire un'operazione di lettura sulla risorsa.

146
00:10:34,170 --> 00:10:39,980
Quindi, il che significa che un client che invia una richiesta GET indica

147
00:10:39,980 --> 00:10:43,480
al server che desidera ottenere una rappresentazione

148
00:10:43,480 --> 00:10:46,380
di quella risorsa dal lato server al lato client.

149
00:10:46,380 --> 00:10:48,960
Un POST significa che si desidera creare

150
00:10:48,960 --> 00:10:52,755
una nuova risorsa e quindi specificare i dettagli della risorsa

151
00:10:52,755 --> 00:10:55,795
nella rappresentazione che viene utilizzata per

152
00:10:55,795 --> 00:10:59,799
specificare la risorsa e quindi inviare tali informazioni sul lato server, in

153
00:10:59,799 --> 00:11:03,285
modo che il server creerà tale risorsa per conto dell'utente.

154
00:11:03,285 --> 00:11:06,370
Un PUT sarebbe la modifica delle risorse e

155
00:11:06,370 --> 00:11:09,955
un DELETE come ci si aspetterebbe è la cancellazione delle risorse.

156
00:11:09,955 --> 00:11:12,995
Quindi, come puoi vedere, i quattro verbi;

157
00:11:12,995 --> 00:11:15,110
GET, POST, PUT e DELETE,

158
00:11:15,110 --> 00:11:19,180
sono mappati nelle quattro operazioni CRUD che è possibile

159
00:11:19,180 --> 00:11:24,035
eseguire su un database che memorizza queste risorse sul lato server, le

160
00:11:24,035 --> 00:11:27,815
operazioni READ, CREATE, UPDATE e DELETE.

161
00:11:27,815 --> 00:11:33,760
Elaborando ulteriormente, HTTP GET è un modo per specificare che si

162
00:11:33,760 --> 00:11:36,950
desidera che le informazioni o

163
00:11:36,950 --> 00:11:40,235
la rappresentazione della risorsa vengano restituite al client dal lato server.

164
00:11:40,235 --> 00:11:43,890
Pertanto, quando si emette una richiesta GET a un endpoint API REST,

165
00:11:43,890 --> 00:11:49,130
si richiede una raccolta di risorse rappresentate dall'

166
00:11:49,130 --> 00:11:57,530
URI o una risorsa specifica identificata dall'ID di quella particolare risorsa,

167
00:11:57,530 --> 00:11:59,490
specificata all'interno dell'URL.

168
00:11:59,490 --> 00:12:01,000
Quindi, come si vede in questo esempio,

169
00:12:01,000 --> 00:12:03,800
se si dice, piatti/452,

170
00:12:03,800 --> 00:12:08,320
si intende dire che il piatto numero 452 con

171
00:12:08,320 --> 00:12:13,075
l'ID 452 dovrebbe essere restituito al lato client.

172
00:12:13,075 --> 00:12:18,175
Allo stesso modo, l'operazione POST come abbiamo visto viene utilizzata per creare la risorsa.

173
00:12:18,175 --> 00:12:20,065
Pertanto, quando si crea la risorsa,

174
00:12:20,065 --> 00:12:26,920
il contenuto della descrizione della risorsa sarebbe sotto forma di una rappresentazione JSON o

175
00:12:26,920 --> 00:12:29,790
una rappresentazione XML e che verrà incluso

176
00:12:29,790 --> 00:12:34,075
nel corpo del messaggio di richiesta inviato al lato server.

177
00:12:34,075 --> 00:12:38,095
Quindi, un'operazione POST prevede una rappresentazione

178
00:12:38,095 --> 00:12:42,870
della risorsa in formato JSON o XML nel corpo del messaggio di richiesta.

179
00:12:42,870 --> 00:12:44,890
Quando il server riceve tale messaggio di richiesta,

180
00:12:44,890 --> 00:12:49,960
il server crea tale risorsa sul lato server e quindi restituisce

181
00:12:49,960 --> 00:12:58,030
una conformazione o un errore per indicare che la creazione della risorsa non è riuscita.

182
00:12:58,030 --> 00:13:02,725
Allo stesso modo, un'operazione PUT viene utilizzata per aggiornare una risorsa.

183
00:13:02,725 --> 00:13:06,315
Quando si esegue un'operazione PUT su una risorsa sul lato server,

184
00:13:06,315 --> 00:13:10,200
è possibile inviare indietro la modifica

185
00:13:10,200 --> 00:13:15,470
specificando solo la modifica parziale che si desidera applicare

186
00:13:15,470 --> 00:13:20,200
sulla particolare risorsa nel corpo del messaggio di risposta oppure è possibile inviare

187
00:13:20,200 --> 00:13:25,345
la rappresentazione completa del nel corpo del messaggio.

188
00:13:25,345 --> 00:13:28,705
A seconda della disposizione tra il client e il server,

189
00:13:28,705 --> 00:13:37,195
il server si aspetta che le informazioni vengano trasmesse nel corpo del messaggio di richiesta.

190
00:13:37,195 --> 00:13:42,600
Un' operazione DELETE come ci si aspetterebbe elimina la risorsa esistente.

191
00:13:42,600 --> 00:13:45,460
Ora, in questo caso particolare,

192
00:13:45,460 --> 00:13:49,670
ovviamente un'operazione DELETE sarebbe idempotente perché se si

193
00:13:49,670 --> 00:13:54,145
tenta di eliminare una risorsa e la risorsa esiste, verrà eliminata.

194
00:13:54,145 --> 00:13:56,445
Se si sta tentando di eliminare una risorsa non esistente,

195
00:13:56,445 --> 00:14:01,220
non causerà ulteriori modifiche sul lato server,

196
00:14:01,220 --> 00:14:06,165
tranne che il server risponderà con un errore che indica che la risorsa non esiste.

197
00:14:06,165 --> 00:14:12,530
Ma, tuttavia, DELETE è un esempio di un'operazione idempotente in questo caso.

198
00:14:12,530 --> 00:14:16,510
Allo stesso modo, l'operazione GET è anche un'operazione idempotente perché

199
00:14:16,510 --> 00:14:20,885
non apporta alcuna modifica alla risorsa sul lato server.

200
00:14:20,885 --> 00:14:26,925
POST e PUT ovviamente modificheranno la risorsa sul lato server,

201
00:14:26,925 --> 00:14:31,940
creeranno una nuova risorsa o modificheranno una risorsa esistente sul lato server.

202
00:14:31,940 --> 00:14:34,060
Naturalmente, le rappresentazioni,

203
00:14:34,060 --> 00:14:36,730
come ho sottolineato, i

204
00:14:36,730 --> 00:14:43,980
due formati comuni per la rappresentazione sono JSON o XML.

205
00:14:43,980 --> 00:14:47,105
L' ultima parte che dobbiamo sottolineare è

206
00:14:47,105 --> 00:14:51,060
che il lato server dovrebbe essere completamente senza stato, il

207
00:14:51,060 --> 00:14:53,640
che significa che il lato server non tiene traccia

208
00:14:53,640 --> 00:14:59,145
dello stato del client perché se il server ha bisogno di tenere traccia dello stato dei client,

209
00:14:59,145 --> 00:15:00,935
non sarà scalabile.

210
00:15:00,935 --> 00:15:05,160
Pertanto, per un'implementazione scalabile del lato server,

211
00:15:05,160 --> 00:15:09,620
normalmente si utilizza un server senza stato sul lato server.

212
00:15:09,620 --> 00:15:12,910
Pertanto, ogni richiesta che il client invia al server verrà

213
00:15:12,910 --> 00:15:16,490
trattata come una richiesta indipendente e

214
00:15:16,490 --> 00:15:20,330
non rifletterà sulle richieste precedenti

215
00:15:20,330 --> 00:15:24,685
che sono già state gestite dal server da quel particolare client.

216
00:15:24,685 --> 00:15:29,605
Quindi, è responsabilità del cliente monitorare il proprio stato,

217
00:15:29,605 --> 00:15:34,635
sia sotto forma di utilizzo dei cookie o utilizzando un database lato client,

218
00:15:34,635 --> 00:15:37,435
qualunque sia il mezzo che sia adatto.

219
00:15:37,435 --> 00:15:41,790
Ora, questo approccio in cui il client tiene traccia del proprio stato è

220
00:15:41,790 --> 00:15:44,815
molto più scalabile perché ogni singolo client

221
00:15:44,815 --> 00:15:48,240
sarà responsabile del monitoraggio del proprio stato.

222
00:15:48,240 --> 00:15:53,840
Questo è dove l'installazione MVC lato client ci aiuta a questo proposito.

223
00:15:53,840 --> 00:15:57,440
Infine, non abbiamo ancora finito con REST.

224
00:15:57,440 --> 00:16:04,145
Vedremo più di REST negli esercizi che seguono in questa particolare lezione

225
00:16:04,145 --> 00:16:12,310
e poi vedremo ulteriori dettagli sull'utilizzo REST nel resto di questo corso.