1
00:00:03,810 --> 00:00:05,895
Nella lezione precedente,

2
00:00:05,895 --> 00:00:07,880
abbiamo appreso l'API REST.

3
00:00:07,880 --> 00:00:10,781
Si è visto come gli endpoint API REST

4
00:00:10,781 --> 00:00:14,990
supportano un modo per un'applicazione client per essere in grado di recuperare

5
00:00:14,990 --> 00:00:23,100
i dati dal server o caricare i dati sul server utilizzando le varie operazioni HTTP.

6
00:00:23,100 --> 00:00:27,062
In questa lezione ed esercizio che segue questa lezione,

7
00:00:27,062 --> 00:00:30,985
esamineremo in modo specifico il tipo di supporto che Express

8
00:00:30,985 --> 00:00:36,545
supporta per la progettazione e l'implementazione di un server basato su API REST.

9
00:00:36,545 --> 00:00:40,085
In particolare, vedremo anche il router Express

10
00:00:40,085 --> 00:00:44,600
e come ci permette di suddividere la nostra applicazione e

11
00:00:44,600 --> 00:00:50,285
quindi organizzarla in più mini applicazioni simili a Express-like,

12
00:00:50,285 --> 00:00:54,495
che si combinano insieme per formare l'applicazione Express, in

13
00:00:54,495 --> 00:01:00,605
particolare quando abbiamo a che fare con varie API REST e parti.

14
00:01:00,605 --> 00:01:02,985
Quindi, per riassumere, nella lezione precedente,

15
00:01:02,985 --> 00:01:06,315
abbiamo esaminato REST in dettaglio.

16
00:01:06,315 --> 00:01:10,560
Abbiamo anche esaminato come ogni endpoint è identificato da un URI,

17
00:01:10,560 --> 00:01:13,950
e come possiamo specificare le varie operazioni da fare su

18
00:01:13,950 --> 00:01:18,295
ogni endpoint utilizzando il verbo HTTP appropriato,

19
00:01:18,295 --> 00:01:20,880
GET, PUT, POST, o DELETE.

20
00:01:20,880 --> 00:01:22,560
Ora, in questa lezione,

21
00:01:22,560 --> 00:01:29,530
vedremo come Express supporta lo sviluppo di un server API REST.

22
00:01:29,530 --> 00:01:35,070
Vedremo il supporto di Express per varie questioni come app.all,

23
00:01:35,070 --> 00:01:38,335
app.get, put, post ed delete

24
00:01:38,335 --> 00:01:43,305
e come questi metodi possono essere utilizzati per costruire un server API REST.

25
00:01:43,305 --> 00:01:50,104
All' interno di Express, i vari gruppi di applicazioni possono essere definiti utilizzando l'app,.

26
00:01:50,104 --> 00:01:51,955
e i vari metodi.

27
00:01:51,955 --> 00:01:59,180
Quindi, app.all specifica un'operazione che deve essere eseguita su tutti i vari verbi,

28
00:01:59,180 --> 00:02:00,990
on, in e part.

29
00:02:00,990 --> 00:02:04,050
Quindi, per esempio, in questo esempio,

30
00:02:04,050 --> 00:02:07,970
vediamo che l'endpoint è definito da/dish,

31
00:02:07,970 --> 00:02:13,230
e quindi l'app.all, qualunque sia specificato nella funzione che viene data per app.all,

32
00:02:13,230 --> 00:02:16,830
verrà applicato a tutte le richieste in arrivo.

33
00:02:16,830 --> 00:02:22,155
L' app.get specifica cosa deve essere fatto per le richieste GET e, di

34
00:02:22,155 --> 00:02:24,233
conseguenza, per le

35
00:02:24,233 --> 00:02:30,015
richieste POST, PUT e DELETE che vengono inviate all'endpoint /dish,

36
00:02:30,015 --> 00:02:32,700
come mostrato in questo esempio.

37
00:02:32,700 --> 00:02:39,471
Express supporta anche la definizione degli endpoint con parametri.

38
00:02:39,471 --> 00:02:45,750
Quindi, ad esempio, è possibile specificare un ID piatto specifico, se lo si desidera,

39
00:02:45,750 --> 00:02:49,500
e quindi lasciare che l'operazione venga eseguita per

40
00:02:49,500 --> 00:02:55,320
quel punto finale specifico riferendosi a quel piatto specifico con un determinato ID di piatto.

41
00:02:55,320 --> 00:02:58,890
Quindi, in questo caso, l'ID piatto stesso è

42
00:02:58,890 --> 00:03:03,706
specificato come parametro e il modello utilizzato per questo è,

43
00:03:03,706 --> 00:03:05,460
come si vede in questo esempio,

44
00:03:05,460 --> 00:03:11,920
/dishes/: e quindi si dovrebbe specificare il parametro qui.

45
00:03:11,920 --> 00:03:14,310
Per renderci più facile da capire,

46
00:03:14,310 --> 00:03:18,060
ho chiamato il parametro come dishId in là.

47
00:03:18,060 --> 00:03:22,035
È possibile utilizzare qualsiasi nome di parametro scelto, ma

48
00:03:22,035 --> 00:03:27,290
l'utilizzo di un nome significativo per un parametro semplifica la comprensione del codice.

49
00:03:27,290 --> 00:03:28,815
Quindi, in questo esempio

50
00:03:28,815 --> 00:03:34,058
, il: dishID significa che se emettiamo una richiesta a un endpoint,

51
00:03:34,058 --> 00:03:38,400
ad esempio, /dishes/23,

52
00:03:38,400 --> 00:03:45,300
allora il parametro dishId ci permette di estrarre questo numero 23 in modo che

53
00:03:45,300 --> 00:03:48,420
possiamo operare sul piatto numero 23 all'interno

54
00:03:48,420 --> 00:03:52,496
della funzione che è specificato all'interno di questo metodo qui.

55
00:03:52,496 --> 00:03:55,190
Quindi, in là, il parametro,

56
00:03:55,190 --> 00:04:01,440
il parametro dishId stesso può essere ottenuto utilizzando l'oggetto request su cui

57
00:04:01,440 --> 00:04:04,020
la proprietà params supportata e

58
00:04:04,020 --> 00:04:08,885
la proprietà params supporta tutti i parametri di richiesta in entrata,

59
00:04:08,885 --> 00:04:10,470
e dishId, in particolare,

60
00:04:10,470 --> 00:04:13,710
è uno di quei parametri di richiesta che ,

61
00:04:13,710 --> 00:04:16,271
come mostrato nel codice qui.

62
00:04:16,271 --> 00:04:22,585
Quando si invia una richiesta PUT o POST dal client al server,

63
00:04:22,585 --> 00:04:28,545
spesso si racchiude i dati nel corpo del messaggio che viene inviato al server.

64
00:04:28,545 --> 00:04:31,110
Ora, il che significa che abbiamo bisogno

65
00:04:31,110 --> 00:04:34,230
di un metodo per estrarre informazioni dal corpo del messaggio.

66
00:04:34,230 --> 00:04:39,320
Quindi questo è dove il middleware del parser del corpo per Express è molto utile.

67
00:04:39,320 --> 00:04:44,805
Quindi il parser corpo ci permette di analizzare le informazioni dal corpo del messaggio.

68
00:04:44,805 --> 00:04:47,515
Per utilizzare il parser corpo, come ci aspetteremmo,

69
00:04:47,515 --> 00:04:52,155
avremmo installare il modulo nodo corpo-parser,

70
00:04:52,155 --> 00:04:56,070
e quindi richiederlo all'interno della nostra applicazione Express,

71
00:04:56,070 --> 00:04:59,550
e quindi specificare app.use (BodyParser).

72
00:04:59,550 --> 00:05:03,570
E se il corpo contiene dati nel formato JSON,

73
00:05:03,570 --> 00:05:05,810
puoi dire BodyParser.json, il

74
00:05:05,810 --> 00:05:09,561
che significa che questo analizzerà solo i dati in

75
00:05:09,561 --> 00:05:14,250
formato JSON racchiusi nel corpo di quel messaggio di richiesta.

76
00:05:14,250 --> 00:05:16,145
In particolare, nell'esercizio,

77
00:05:16,145 --> 00:05:22,620
analizzeremo i dati in entrata che vengono inviati sotto forma di una stringa JSON.

78
00:05:22,620 --> 00:05:24,930
Il parser corpo, come ci si aspetterebbe,

79
00:05:24,930 --> 00:05:30,480
analizza il corpo del messaggio e popola la proprietà req.body.

80
00:05:30,480 --> 00:05:32,190
Quindi, sulla richiesta,

81
00:05:32,190 --> 00:05:36,250
la proprietà body conterrà tutto ciò che viene analizzato dal

82
00:05:36,250 --> 00:05:41,600
corpo del messaggio di richiesta dal parser corpo.

83
00:05:41,600 --> 00:05:45,030
Se si sta implementando un'applicazione Express

84
00:05:45,030 --> 00:05:48,465
che supporta più endpoint API REST,

85
00:05:48,465 --> 00:05:53,265
allora ha senso suddividere il codice in

86
00:05:53,265 --> 00:05:59,520
più moduli e quindi utilizzarli per costruire l'applicazione Express complessiva.

87
00:05:59,520 --> 00:06:03,347
Quindi questo dove il router Express viene in nostro aiuto.

88
00:06:03,347 --> 00:06:08,070
Un router Express definisce molte applicazioni Express

89
00:06:08,070 --> 00:06:10,045
e all'interno di tale molte applicazioni Express,

90
00:06:10,045 --> 00:06:11,480
è possibile, ad esempio,

91
00:06:11,480 --> 00:06:16,550
gestire un particolare endpoint API REST in modo più dettagliato,

92
00:06:16,550 --> 00:06:20,215
o un particolare modello di endpoint API REST in modo più dettagliato.

93
00:06:20,215 --> 00:06:27,656
Quindi, ad esempio, possiamo definire un DishRouter come Express.Router,

94
00:06:27,656 --> 00:06:32,450
e quindi DishRouter può quindi gestire gli endpoint.

95
00:06:32,450 --> 00:06:35,420
Quindi, quando esprimi qualcosa come Express.router,

96
00:06:35,420 --> 00:06:38,570
supporta l'endpoint di route.

97
00:06:38,570 --> 00:06:41,015
Uno dei motivi per l'utilizzo del router Express,

98
00:06:41,015 --> 00:06:42,455
come ti renderai conto,

99
00:06:42,455 --> 00:06:45,470
è che se usiamo i

100
00:06:45,470 --> 00:06:47,142
metodi GET, PUT, POST e DELETE dell'app standard,

101
00:06:47,142 --> 00:06:48,760
per ciascuno di questi metodi,

102
00:06:48,760 --> 00:06:52,315
è necessario specificare esplicitamente gli endpoint dell'API REST.

103
00:06:52,315 --> 00:06:55,130
Un vantaggio dell'utilizzo del router Express è che se si

104
00:06:55,130 --> 00:06:59,422
dice il router.route e quindi si specifica l'endpoint,

105
00:06:59,422 --> 00:07:07,220
tale endpoint verrà applicato a tutti i metodi e tutti i vari

106
00:07:07,220 --> 00:07:11,060
metodi GET, PUT, POST e DELETE verbo possono essere concatenati

107
00:07:11,060 --> 00:07:16,575
insieme nel percorso nella definizione del codice per la nostra applicazione.

108
00:07:16,575 --> 00:07:22,075
Vedremo maggiori dettagli di questo nell'esercizio che segue questa lezione.

109
00:07:22,075 --> 00:07:27,505
Con questa rapida comprensione di come Express supporta l'endpoint API REST,

110
00:07:27,505 --> 00:07:31,070
passiamo all'esercizio in cui costruiremo il

111
00:07:31,070 --> 00:07:35,682
loro supporto per l'endpoint API REST /dish.

112
00:07:35,682 --> 00:07:38,180
Come parte della prima assegnazione,

113
00:07:38,180 --> 00:07:40,160
si estenderà ulteriormente

114
00:07:40,160 --> 00:07:44,559
questa applicazione Express per supportare endpoint API REST aggiuntivi,

115
00:07:44,559 --> 00:07:48,990
tra cui /promotions e/leaders.

116
00:07:48,990 --> 00:07:52,040
Se hai seguito i corsi precedenti nella specializzazione,

117
00:07:52,040 --> 00:07:55,220
inizierai immediatamente a capire perché stiamo supportando

118
00:07:55,220 --> 00:08:00,810
tutti questi diversi endpoint API REST dall'altro lato server.