1
00:00:03,979 --> 00:00:06,750
Lascia che ti dia un breve riposo.

2
00:00:08,010 --> 00:00:09,480
Ti ho beccato lì!

3
00:00:09,480 --> 00:00:10,800
Quello che volevo dire era:

4
00:00:10,800 --> 00:00:16,860
lasciatemi dare una breve panoramica sul trasferimento dello stato rappresentativo.

5
00:00:16,860 --> 00:00:18,670
Cos' è esattamente il riposo?

6
00:00:18,670 --> 00:00:22,900
Come facciamo a usarlo nella nostra applicazione angolare e

7
00:00:22,900 --> 00:00:26,450
come facciamo a utilizzare questo per comunicare con il server?

8
00:00:26,450 --> 00:00:30,050
In che modo un server supporta l'API REST e

9
00:00:30,050 --> 00:00:35,060
come accediamo all'API REST dalla nostra applicazione Angular?

10
00:00:35,060 --> 00:00:39,170
Parliamone un po' di più in questa lezione.

11
00:00:39,170 --> 00:00:43,880
In questa particolare lezione, ti darò una breve panoramica di REST.

12
00:00:46,010 --> 00:00:50,620
Sono sicuro che il termine Web Services viene menzionato

13
00:00:50,620 --> 00:00:53,990
molto spesso nel mondo IT.

14
00:00:53,990 --> 00:00:56,160
Che cosa sono esattamente i servizi web?

15
00:00:56,160 --> 00:01:01,980
I servizi Web sono un modo di progettare sistemi per supportare l'interoperabilità tra

16
00:01:01,980 --> 00:01:07,920
i sistemi collegati su una rete, come Internet come vediamo oggi.

17
00:01:07,920 --> 00:01:11,830
Questo è ciò che definiamo un'architettura orientata ai servizi.

18
00:01:11,830 --> 00:01:18,100
Ora, ciò significa che si fornisce un modo standardizzato per due macchine

19
00:01:18,100 --> 00:01:22,190
che sono collegate a Internet per essere in grado di comunicare tra loro.

20
00:01:23,670 --> 00:01:26,970
Il loro livello di layout dell'applicazione per

21
00:01:26,970 --> 00:01:30,920
le applicazioni di database che utilizzano standard aperti.

22
00:01:30,920 --> 00:01:34,660
Ora, ho usato un sacco di gergo lì.

23
00:01:35,710 --> 00:01:37,420
Proviamo a suddividerli e

24
00:01:37,420 --> 00:01:41,640
capire un po 'di ciascuno di questi in questa lezione.

25
00:01:42,640 --> 00:01:49,570
Due approcci comuni utilizzati per supportare i servizi Web sono SOAP,

26
00:01:49,570 --> 00:01:54,720
i semplici servizi Web basati sul protocollo di accesso agli oggetti,

27
00:01:54,720 --> 00:01:58,820
che utilizza il linguaggio di descrizione dei servizi Web per

28
00:01:58,820 --> 00:02:03,150
specificare il modo in cui i due endpoint comunicano tra loro.

29
00:02:03,150 --> 00:02:07,667
E in genere, soap si basa sull'utilizzo di XML come

30
00:02:07,667 --> 00:02:12,240
formato per i messaggi scambiati tra i due endpoint.

31
00:02:13,990 --> 00:02:19,910
Il trasferimento dello stato di presentazione o resto utilizza anche gli standard web, ma lo scambio

32
00:02:19,910 --> 00:02:24,020
di dati tra i due endpoint potrebbe essere XML o sempre più.

33
00:02:25,150 --> 00:02:28,960
Utilizzo di JSON come formato.

34
00:02:28,960 --> 00:02:34,960
Il modo REST di interoperabilità è più semplice rispetto a SOAP e

35
00:02:34,960 --> 00:02:42,940
quindi REST ha trovato una distribuzione molto più ampia nei servizi web rimasti.

36
00:02:43,950 --> 00:02:49,230
In genere, la comunicazione del server client è facilitata utilizzando REST

37
00:02:49,230 --> 00:02:54,830
in cui il server supporta l'API REST e il client può quindi richiamare i loro

38
00:02:54,830 --> 00:03:01,000
endpoint API REST al fine di ottenere informazioni o caricare informazioni sul server.

39
00:03:01,000 --> 00:03:05,910
Ancora una volta, ho menzionato la parola, invocare quel punto finale dell'API REST.

40
00:03:05,910 --> 00:03:09,290
Quindi questi sono alcuni termini che ho usato.

41
00:03:09,290 --> 00:03:12,460
Cerchiamo di chiarire alcuni di questi nelle prossime diapositive.

42
00:03:13,790 --> 00:03:18,710
Il trasferimento dello stato rappresentativo è uno stile di architettura software

43
00:03:18,710 --> 00:03:23,360
appositamente progettato per gli hypermedia distribuiti sul World Wide Web.

44
00:03:24,770 --> 00:03:30,810
Ora questo è stato introdotto per la prima volta da Roy Fielding nella sua tesi di dottorato.

45
00:03:30,810 --> 00:03:33,750
Ora, questa è una di quelle tesi di dottorato che in realtà ha prodotto

46
00:03:33,750 --> 00:03:35,970
qualcosa di utile per il mondo.

47
00:03:35,970 --> 00:03:44,250
Quindi questo ha trovato ancora un sacco di trazione nel mondo dei servizi web.

48
00:03:44,250 --> 00:03:50,410
Si tratta di una raccolta di principi di rete che illustrano come le risorse possono essere

49
00:03:51,630 --> 00:03:57,060
rese disponibili sui server e a queste risorse è possibile accedere

50
00:03:57,060 --> 00:04:02,520
dai client identificando le risorse utilizzando gli endpoint API REST.

51
00:04:02,520 --> 00:04:07,150
All' interno del trasferimento dello stato rappresentativo ci sono quattro principi di progettazione di base.

52
00:04:07,150 --> 00:04:11,310
Innanzitutto, REST è costruito sul protocollo HTTP.

53
00:04:11,310 --> 00:04:17,800
Quindi utilizza tutti i metodi HTTP che abbiamo già visto nella lezione precedente.

54
00:04:17,800 --> 00:04:22,750
In secondo luogo, REST è progettato per essere senza stato, il che significa che il server non memorizza

55
00:04:22,750 --> 00:04:27,350
alcuna informazione sullo stato dopo che la comunicazione è stata completata.

56
00:04:27,350 --> 00:04:31,850
Quindi, quando un server riceve la richiesta, il server risponde e

57
00:04:31,850 --> 00:04:37,020
poi, dopo, non ricorda nulla di più su quella

58
00:04:37,020 --> 00:04:39,730
conversazione tra il client e il server.

59
00:04:39,730 --> 00:04:44,620
In terzo luogo, il modo REST di fornire risorse consiste nell'

60
00:04:44,620 --> 00:04:49,990
esporre una struttura di directory come URL di localizzatori di risorse uniformi.

61
00:04:51,090 --> 00:04:57,210
E quarto il loro formato per lo scambio di dati è in genere JSON o

62
00:04:57,210 --> 00:05:02,360
XML, o entrambi che possono essere supportati utilizzando REST.

63
00:05:02,360 --> 00:05:07,940
Una delle motivazioni per l'aumento suggerendo REST come un modo per supportare

64
00:05:07,940 --> 00:05:14,060
i servizi web è che cattura tutto ciò che è buono di tutto il World Wide Web.

65
00:05:14,060 --> 00:05:17,130
E questo ha reso il Word Wide Web di successo.

66
00:05:17,130 --> 00:05:23,240
L' uso di Uniform Resource Indicators o Uniform Resource Locator, URL,

67
00:05:23,240 --> 00:05:28,660
che consentono di indirizzare le risorse specificandole come URL,

68
00:05:28,660 --> 00:05:35,370
il secondo è un protocollo che si basa sul protocollo HTTP.

69
00:05:35,370 --> 00:05:40,820
HTTP ha già trovato un'ampia distribuzione in Internet.

70
00:05:40,820 --> 00:05:46,370
In terzo luogo, il ciclo di risposta della richiesta che HTTP è ben noto per.

71
00:05:46,370 --> 00:05:51,850
Quindi si invia una richiesta, il server riceve la richiesta, elabora la richiesta,

72
00:05:51,850 --> 00:05:57,835
invia la risposta alla richiesta e quel client riceve la risposta,

73
00:05:57,835 --> 00:06:00,845
agisce su di essa e può generare ulteriori richieste.

74
00:06:00,845 --> 00:06:06,815
Quindi, questo approccio del ciclo di risposta richiesta è molto ben stabilito con HTTP

75
00:06:06,815 --> 00:06:14,740
e il protocollo Web HTTP mondiale come abbiamo visto in precedenza,

76
00:06:14,740 --> 00:06:19,670
useremo tutti i vari verbi che HTTP fornisce.

77
00:06:19,670 --> 00:06:23,120
In particolare, il cancello messo post cancella.

78
00:06:23,120 --> 00:06:26,730
Per essere in grado di specificare le operazioni da eseguire

79
00:06:26,730 --> 00:06:29,680
sulle risorse che sono memorizzate sul lato server.

80
00:06:29,680 --> 00:06:34,320
Ad esempio, se si esegue una richiesta HTTP GET, si sta chiedendo

81
00:06:34,320 --> 00:06:36,180
al server di restituire l'origine.

82
00:06:36,180 --> 00:06:41,410
Se si esegue una richiesta POST, si sta chiedendo al server di creare una nuova risorsa.

83
00:06:41,410 --> 00:06:44,330
Se si esegue una richiesta PUT, si sta chiedendo al server di aggiornare

84
00:06:44,330 --> 00:06:48,780
una risorsa esistente e se si emette una richiesta di eliminazione si sta chiedendo

85
00:06:48,780 --> 00:06:54,210
al server di eliminare la risorsa identificata da quel particolare URL.

86
00:06:54,210 --> 00:06:57,890
Inoltre, cerca di preservare l'idempotenza.

87
00:06:57,890 --> 00:07:00,970
Alcune operazioni quando vengono eseguite

88
00:07:00,970 --> 00:07:04,370
Anche ripetutamente non causerà alcun cambiamento di stato.

89
00:07:04,370 --> 00:07:08,160
Alcune altre operazioni, se le fai successivamente,

90
00:07:08,160 --> 00:07:11,170
potrebbero causare un cambiamento di stato.

91
00:07:11,170 --> 00:07:14,780
Quindi è necessario fare attenzione a quali operazioni possono essere ripetute

92
00:07:14,780 --> 00:07:16,660
senza conseguenze dannose.

93
00:07:16,660 --> 00:07:19,570
E che devono essere fatti con molta attenzione.

94
00:07:21,070 --> 00:07:25,530
Nel mondo REST, spesso si sente parlare di nomi,

95
00:07:25,530 --> 00:07:28,230
verbi e rappresentazioni.

96
00:07:28,230 --> 00:07:34,120
Ora chiariremo ognuno di questi in modo un po 'più dettagliato nelle prossime diapositive.

97
00:07:34,120 --> 00:07:36,720
I nomi, in particolare, sono pieni di risorse e

98
00:07:36,720 --> 00:07:42,580
queste risorse sono solitamente identificate dai loro URL e queste non sono vincolate. I

99
00:07:42,580 --> 00:07:48,890
verbi sono vincolati e queste azioni specificate da fare sulle risorse.

100
00:07:48,890 --> 00:07:53,200
E le presentazioni come vediamo quando le informazioni devono essere trasmesse

101
00:07:53,200 --> 00:07:54,560
dal server al client o

102
00:07:54,560 --> 00:07:58,150
dal client al server, come codificare le informazioni.

103
00:07:58,150 --> 00:08:02,840
In genere utilizzando JSON o XML. La

104
00:08:02,840 --> 00:08:08,150
risorsa è l'astrazione chiave che REST funziona in modo

105
00:08:08,150 --> 00:08:11,787
che le informazioni vengano astratte nella risorsa.

106
00:08:11,787 --> 00:08:18,690
E la risorsa viene identificata specificandola utilizzando un URI.

107
00:08:18,690 --> 00:08:23,040
Quindi qualsiasi informazione che può essere incapsulata e

108
00:08:23,040 --> 00:08:26,980
resa disponibile può essere identificata come una risorsa.

109
00:08:26,980 --> 00:08:33,145
Un pezzo di informazioni come il tempo attuale a Hong Kong potrebbe essere una risorsa,

110
00:08:33,145 --> 00:08:35,465
un'immagine potrebbe essere una risorsa.

111
00:08:35,465 --> 00:08:39,915
Un' informazione sul prezzo delle azioni potrebbe essere una risorsa, e così via.

112
00:08:39,915 --> 00:08:43,905
Quindi qualunque cosa tu definisca come un'informazione a cui un cliente potrebbe essere

113
00:08:43,905 --> 00:08:47,515
interessato, può essere identificata come una risorsa.

114
00:08:47,515 --> 00:08:50,965
È anche possibile gestire le risorse come raccolta di risorse

115
00:08:50,965 --> 00:08:55,070
che il server può inviare a quel client.

116
00:08:55,070 --> 00:09:00,380
Qui viene illustrato un esempio di come nominare le risorse.

117
00:09:00,380 --> 00:09:03,898
Quindi usiamo URI per identificare la fonte.

118
00:09:03,898 --> 00:09:09,575
Una rapida lettura delle specifiche o degli URL qui

119
00:09:09,575 --> 00:09:16,525
vi permetterà facilmente di capire a cosa ci riferiamo utilizzando questi URL.

120
00:09:16,525 --> 00:09:19,675
Quindi, per esempio, qualcosa che termina con i piatti/,

121
00:09:19,675 --> 00:09:25,495
si assume automaticamente che questo si riferisce a una raccolta di piatti.

122
00:09:25,495 --> 00:09:28,909
Come piatti/123 per esempio,

123
00:09:28,909 --> 00:09:34,150
potrebbe significare piatto numero 123, in questo caso e così via.

124
00:09:34,150 --> 00:09:39,530
Quindi è molto facile dire che è possibile specificare una raccolta di risorse, ed

125
00:09:39,530 --> 00:09:43,800
essere in grado di identificarle come una raccolta, e quindi scaricarle come una raccolta. In

126
00:09:43,800 --> 00:09:46,960
alternativa, è possibile identificare una singola risorsa e

127
00:09:46,960 --> 00:09:50,070
dire che si desidera quella particolare risorsa.

128
00:09:50,070 --> 00:09:53,378
Ora queste risorse possono essere organizzate in una gerarchia

129
00:09:53,378 --> 00:09:56,500
che specifica di questo URI.

130
00:09:56,500 --> 00:09:58,860
Quindi, mentre attraversi il percorso,

131
00:09:58,860 --> 00:10:04,460
passi dal più generale al più specifico di quella risorsa.

132
00:10:04,460 --> 00:10:08,260
Questa struttura di directory consente di identificare le risorse

133
00:10:09,320 --> 00:10:14,170
fornite dal sito del servizio in modo molto semplice.

134
00:10:14,170 --> 00:10:17,970
La seconda parte dell'API REST sono le parole.

135
00:10:17,970 --> 00:10:22,150
In particolare siamo interessati ai 4 verbi di HTTP da ottenere,

136
00:10:22,150 --> 00:10:25,320
mettere, pubblicare ed eliminare.

137
00:10:25,320 --> 00:10:30,310
In questo caso questi verbi saranno pisolino in azioni che

138
00:10:30,310 --> 00:10:36,165
vogliamo essere eseguite sulla risorsa sul lato server.

139
00:10:36,165 --> 00:10:40,760
GetT significa che si desidera eseguire un'operazione di lettura sulla risorsa, il

140
00:10:40,760 --> 00:10:46,550
che significa che un client che invia una richiesta get indica al server

141
00:10:46,550 --> 00:10:52,710
che desidera ottenere la presentazione dell'origine dati dal sito server al sito client.

142
00:10:52,710 --> 00:10:56,770
POST significa che vuoi creare una nuova risorsa e poi lo farai.

143
00:10:56,770 --> 00:11:01,700
Specificare i dettagli della risorsa nella rappresentazione, ma viene utilizzato per

144
00:11:01,700 --> 00:11:02,850
specificare la risorsa.

145
00:11:02,850 --> 00:11:05,900
Quindi inviare le informazioni sul lato server, in modo

146
00:11:05,900 --> 00:11:09,590
che il server creerà la risorsa per conto dell'utente.

147
00:11:09,590 --> 00:11:12,310
Un PUT sarebbe la modifica delle risorse e l'

148
00:11:12,310 --> 00:11:16,030
eliminazione, come ci si aspetterebbe, è la cancellazione delle fonti.

149
00:11:16,030 --> 00:11:20,550
Quindi, come puoi vedere i quattro verbi get, post, put ed

150
00:11:20,550 --> 00:11:25,670
delete sono mappati nelle quattro operazioni CRUD che puoi eseguire

151
00:11:25,670 --> 00:11:30,140
su un database che memorizza queste risorse sul lato server.

152
00:11:30,140 --> 00:11:34,130
Le operazioni di lettura, creazione, aggiornamento ed eliminazione.

153
00:11:34,130 --> 00:11:39,140
Elaborando ulteriormente, HTTP GET è un modo di specificare.

154
00:11:39,140 --> 00:11:43,560
Che si desidera che le informazioni o la loro presentazione della risorsa vengano

155
00:11:43,560 --> 00:11:46,280
restituite al client dal sito server.

156
00:11:46,280 --> 00:11:49,980
Quindi, quando si emette una richiesta GET a un endpoint API REST.

157
00:11:49,980 --> 00:11:54,370
Stai chiedendo una raccolta di risorse che sono presentate da

158
00:11:55,890 --> 00:12:01,790
Uri o una risorsa specifica che è identificata dall'ID di

159
00:12:01,790 --> 00:12:06,950
quelle particolari risorse specificate all'interno dell'URL in modo che vedi in questo esempio,

160
00:12:06,950 --> 00:12:13,090
se piatti/452, intendi dire quel piatto numero 452,

161
00:12:13,090 --> 00:12:16,950
con il id 452 deve essere restituito al lato client.

162
00:12:19,370 --> 00:12:24,210
Allo stesso modo, l'operazione post, come abbiamo visto, viene utilizzata per creare la risorsa.

163
00:12:24,210 --> 00:12:29,940
Quindi, quando si crea la risorsa, il contenuto della descrizione

164
00:12:29,940 --> 00:12:34,830
della risorsa sarebbe sotto forma di una rappresentazione JSON o una rappresentazione XML e che sarebbe

165
00:12:34,830 --> 00:12:40,220
incluso nel corpo del messaggio di richiesta inviato al lato server.

166
00:12:40,220 --> 00:12:43,900
Quindi un'operazione post si aspetta una rappresentazione

167
00:12:43,900 --> 00:12:49,040
della risorsa in formato JSON o XML nel corpo del messaggio di richiesta.

168
00:12:49,040 --> 00:12:53,250
E il server riceve tale messaggio di richiesta, il server crea tale

169
00:12:53,250 --> 00:12:58,440
risorsa sul lato server e quindi restituisce una conferma o

170
00:12:58,440 --> 00:13:04,390
un errore per indicare che la creazione della risorsa non è riuscita.

171
00:13:04,390 --> 00:13:08,820
Allo stesso modo mette l'operazione facile da usare per aggiornare una risorsa.

172
00:13:08,820 --> 00:13:14,630
Quando si esegue un'operazione PUT su una risorsa sul lato server, è possibile inviare indietro

173
00:13:14,630 --> 00:13:19,630
la modifica specificando solo la modifica parziale

174
00:13:19,630 --> 00:13:25,450
che si desidera applicare sulla particolare risorsa nel corpo del messaggio di risposta.

175
00:13:25,450 --> 00:13:29,370
Oppure è possibile inviare la rappresentazione completa della risorsa

176
00:13:29,370 --> 00:13:33,890
nel corpo del messaggio, a seconda della disposizione tra il client e

177
00:13:33,890 --> 00:13:38,760
il server, il server si aspetta che le informazioni vengano

178
00:13:38,760 --> 00:13:43,320
trasmesse nel corpo del messaggio di richiesta.

179
00:13:43,320 --> 00:13:48,980
L' operazione DELETE come ci si aspetterebbe elimina la risorsa esistente.

180
00:13:48,980 --> 00:13:55,150
Ora, in questo caso particolare, ovviamente, un'operazione di eliminazione sarebbe perché

181
00:13:55,150 --> 00:14:00,220
se si tenta di eliminare una risorsa e la risorsa esiste, verrà eliminata.

182
00:14:00,220 --> 00:14:02,440
Se si sta tentando di eliminare una risorsa non esistente,

183
00:14:02,440 --> 00:14:07,990
non causerà ulteriori modifiche sul lato server Ad eccezione del fatto

184
00:14:07,990 --> 00:14:11,808
che il server risponderà con un errore che dice che la risorsa non esiste.

185
00:14:11,808 --> 00:14:18,700
Ma tuttavia, è un esempio di un'operazione in questo caso.

186
00:14:18,700 --> 00:14:22,810
Analogamente, l'operazione get funzionerà anche perché non

187
00:14:22,810 --> 00:14:27,140
apporta alcuna modifica alla risorsa sul sito server.

188
00:14:27,140 --> 00:14:32,740
L' input post ovviamente modificherà la risorsa sul lato server.

189
00:14:32,740 --> 00:14:34,770
È necessario creare una nuova risorsa o

190
00:14:34,770 --> 00:14:40,050
modificare la risorsa esistente sul lato server e, naturalmente, presentazioni di dati.

191
00:14:40,050 --> 00:14:45,050
Come ho sottolineato, i due fallback comuni per la

192
00:14:45,050 --> 00:14:51,570
rappresentazione sono JSON XML, l'ultima parte

193
00:14:51,570 --> 00:14:57,140
che dobbiamo sottolineare è che il lato server dovrebbe essere completamente senza stato. Il

194
00:14:57,140 --> 00:15:01,190
che significa che il lato server non tiene traccia dello stato del client.

195
00:15:01,190 --> 00:15:07,060
Perché, se il server deve tenere traccia dello stato del client, non sarà scalabile.

196
00:15:07,060 --> 00:15:11,140
Quindi, per un'implementazione scalabile del lato server,

197
00:15:11,140 --> 00:15:15,650
normalmente si utilizza un server senza stato sul lato server.

198
00:15:15,650 --> 00:15:19,580
Quindi, se la richiesta dei client inviati al server verrà trattata come

199
00:15:19,580 --> 00:15:25,460
una richiesta indipendente e non rifletterà sulle

200
00:15:25,460 --> 00:15:30,790
richieste precedenti che sono già state gestite dal server dal particolare client.

201
00:15:30,790 --> 00:15:35,760
Quindi è responsabilità del cliente rintracciare il proprio stato.

202
00:15:35,760 --> 00:15:40,770
O sotto forma di utilizzo di cookie o utilizzo di un database del sito client.

203
00:15:40,770 --> 00:15:43,780
Qualunque sia il mezzo che sia adatto.

204
00:15:43,780 --> 00:15:48,760
Ora, questo approccio in cui il client tiene traccia del proprio stato è molto più scalabile,

205
00:15:48,760 --> 00:15:52,880
perché il tuo client sarà responsabile del monitoraggio del proprio.

206
00:15:54,340 --> 00:15:58,880
E questo è dove l'installazione MVC lato client ci aiuta a questo proposito.

207
00:16:00,100 --> 00:16:04,920
E infine non abbiamo ancora finito con REST, vedremo più di

208
00:16:04,920 --> 00:16:10,280
REST negli esercizi che seguono in questa particolare lezione.

209
00:16:10,280 --> 00:16:11,563
E poi,

210
00:16:11,563 --> 00:16:17,206
vedremo ulteriori dettagli sull'utilizzo REST nel resto di questo corso.

211
00:16:17,206 --> 00:16:20,509
[ MUSIC]