1
00:00:03,940 --> 00:00:08,444
In questo modulo nella prima lezione,

2
00:00:08,444 --> 00:00:14,115
abbiamo imparato come costruire un server API REST completo usando express.

3
00:00:14,115 --> 00:00:17,120
Quindi siamo in grado di servire le

4
00:00:17,120 --> 00:00:22,185
richieste GET, PUT, POST e DELETE che arrivano ai vari endpoint API REST.

5
00:00:22,185 --> 00:00:24,975
Ma il server stesso stava semplicemente restituendo

6
00:00:24,975 --> 00:00:29,115
un semplice messaggio in risposta a queste richieste.

7
00:00:29,115 --> 00:00:32,778
In un vero server API REST,

8
00:00:32,778 --> 00:00:39,620
qualsiasi richiesta in entrata comporterà un'operazione corrispondente da eseguire sul retro

9
00:00:39,620 --> 00:00:46,610
del database forse per recuperare i dati per rispondere a una richiesta GET,

10
00:00:46,610 --> 00:00:52,430
o forse per modificare i dati esistenti sul server in risposta a una richiesta PUT.

11
00:00:52,430 --> 00:00:56,270
Ora nel resto di questo modulo,

12
00:00:56,270 --> 00:01:03,465
abbiamo studiato su come possiamo interagire da un'applicazione nodo con un server MongoDB,

13
00:01:03,465 --> 00:01:10,500
che si tratti di utilizzare il driver MongoDB o utilizzando Mongoose.

14
00:01:10,500 --> 00:01:15,600
Ora, un server API REST completo in grado di gestire

15
00:01:15,600 --> 00:01:21,468
la richiesta end-to-end sarà possibile solo quando combiniamo i due insieme.

16
00:01:21,468 --> 00:01:24,840
Cioè, un server basato su express che esegue

17
00:01:24,840 --> 00:01:29,340
tutta l'elaborazione della logica di business e allo stesso tempo emetterà

18
00:01:29,340 --> 00:01:34,200
le richieste di database al MongoDB

19
00:01:34,200 --> 00:01:40,790
utilizzando il driver MongoDB nodo o utilizzando Mongoose.

20
00:01:40,790 --> 00:01:42,780
Allora, come combiniamo i due insieme?

21
00:01:42,780 --> 00:01:47,040
Quindi questo è ciò che vedremo in questa particolare lezione,

22
00:01:47,040 --> 00:01:51,230
e i due esercizi che faremo come parte di questa lezione.

23
00:01:51,230 --> 00:01:55,875
Ora abbiamo imparato come costruire

24
00:01:55,875 --> 00:01:59,400
un server API REST utilizzando Express

25
00:01:59,400 --> 00:02:03,950
e servire le varie richieste che arrivano ai punti finali dell'API REST.

26
00:02:03,950 --> 00:02:10,765
Abbiamo anche visto come possiamo interagire con il database dalla nostra applicazione nodo.

27
00:02:10,765 --> 00:02:17,280
Ora, dato che si dispone di una richiesta GET che entra nel server come esempio,

28
00:02:17,280 --> 00:02:20,550
per gestire questa richiesta GET end-to-end,

29
00:02:20,550 --> 00:02:25,500
una richiesta GET proveniente dal client significa che il client desidera recuperare

30
00:02:25,500 --> 00:02:31,830
i dati dal server e utilizzare tali dati.

31
00:02:31,830 --> 00:02:34,590
Quindi, una richiesta GET che entra nel server dovrà essere

32
00:02:34,590 --> 00:02:39,060
gestita attraverso le varie elaborazioni effettuate da, ad esempio,

33
00:02:39,060 --> 00:02:43,880
il server Express e una volta che l'elaborazione è fatto, la

34
00:02:43,880 --> 00:02:47,340
logica aziendale del server Express si rende conto che ha bisogno di

35
00:02:47,340 --> 00:02:51,166
eseguire un'operazione di query sul database.

36
00:02:51,166 --> 00:02:54,630
Quindi, questo può avviare una query al database per

37
00:02:54,630 --> 00:02:58,605
recuperare un set di documenti dal database,

38
00:02:58,605 --> 00:03:02,850
e quindi i dati recuperati verranno quindi

39
00:03:02,850 --> 00:03:07,650
trasformati in un messaggio di risposta e quindi inviati al server.

40
00:03:07,650 --> 00:03:15,340
Quindi questa gestione end-to-end della richiesta e della risposta coinvolge due parti.

41
00:03:15,340 --> 00:03:18,060
Uno ovviamente facendo la logica di business

42
00:03:18,060 --> 00:03:23,070
nel server Express e quindi facendo l'interazione con

43
00:03:23,070 --> 00:03:27,270
il database dall'applicazione nodo dal server Express che è

44
00:03:27,270 --> 00:03:32,580
un'applicazione nodo che utilizza il driver MongoDB o Mongoose.

45
00:03:32,580 --> 00:03:36,190
Useremo Mangusta negli esercizi.

46
00:03:36,190 --> 00:03:42,005
Allo stesso modo, una richiesta POST che arriva

47
00:03:42,005 --> 00:03:46,420
al punto finale dell'API REST sul server significa che

48
00:03:46,420 --> 00:03:51,330
la richiesta POST porta alcuni dati nel corpo del messaggio.

49
00:03:51,330 --> 00:03:55,795
Quindi, queste informazioni devono essere elaborate nel server Express

50
00:03:55,795 --> 00:04:01,150
e le informazioni che devono essere memorizzate

51
00:04:01,150 --> 00:04:07,208
nel database devono essere recuperate dal corpo della richiesta POST in arrivo e quindi la

52
00:04:07,208 --> 00:04:11,380
richiesta di creazione corrispondente deve

53
00:04:11,380 --> 00:04:17,590
essere creata o avviata dal server Express a il database MongoDB

54
00:04:17,590 --> 00:04:19,450
e nella richiesta di creazione,

55
00:04:19,450 --> 00:04:22,330
le informazioni che sono state recuperate dal corpo

56
00:04:22,330 --> 00:04:25,870
della richiesta POST verranno inviate

57
00:04:25,870 --> 00:04:33,130
al database per creare un nuovo documento in una raccolta specifica sul database.

58
00:04:33,130 --> 00:04:36,550
E quindi il risultato di questa operazione verrà

59
00:04:36,550 --> 00:04:40,200
inviato al client nel messaggio di risposta.

60
00:04:40,200 --> 00:04:45,640
Quindi, qualsiasi operazione eseguita su un punto finale API REST se si tratta di un GET,

61
00:04:45,640 --> 00:04:47,155
un PUT, un POST

62
00:04:47,155 --> 00:04:48,951
o un'operazione DELETE,

63
00:04:48,951 --> 00:04:51,005
come si vede da questi due esempi,

64
00:04:51,005 --> 00:04:58,063
avvierà un'operazione di database corrispondente dietro le quinte.

65
00:04:58,063 --> 00:05:01,120
Quindi, avendo capito questa interazione,

66
00:05:01,120 --> 00:05:05,590
ciò che ci rendiamo conto è che una richiesta HTTP che arriva a

67
00:05:05,590 --> 00:05:10,360
un endpoint API REST deve essere mappata in un'operazione di database corrispondente.

68
00:05:10,360 --> 00:05:12,260
Quindi ogni richiesta in arrivo, GET, PUT, POST

69
00:05:12,260 --> 00:05:19,270
o DELETE significa che è possibile accedere a una risorsa specifica sul database,

70
00:05:19,270 --> 00:05:23,530
può essere recuperata o un gruppo di risorse può essere

71
00:05:23,530 --> 00:05:28,360
recuperato dal database e quindi inviato al server,

72
00:05:28,360 --> 00:05:34,015
o una risorsa può essere modificata in risposta a un PUT o a un POST

73
00:05:34,015 --> 00:05:40,425
o anche una richiesta DELETE in arrivo al server API REST.

74
00:05:40,425 --> 00:05:44,170
Quindi spetta alla logica del server Express,

75
00:05:44,170 --> 00:05:47,545
la logica aziendale implementata nel server API REST Express,

76
00:05:47,545 --> 00:05:53,860
gestire questa traduzione della richiesta in arrivo sia che si tratti di una richiesta GET,

77
00:05:53,860 --> 00:05:58,765
PUT, POST o DELETE nell'operazione di database corrispondente.

78
00:05:58,765 --> 00:06:03,085
Quindi diamo un'occhiata a un esempio di questo in un po 'più in dettaglio.

79
00:06:03,085 --> 00:06:07,480
Quindi, arrivando alla combinazione del router Express più

80
00:06:07,480 --> 00:06:12,445
MongoDB più Mongoose che agisce come ODM in mezzo,

81
00:06:12,445 --> 00:06:17,710
le operazioni da eseguire del database devono essere avviate

82
00:06:17,710 --> 00:06:23,275
all'interno del router che abbiamo costruito per ciascuno degli endpoint API REST.

83
00:06:23,275 --> 00:06:24,310
Quindi all'interno del router,

84
00:06:24,310 --> 00:06:26,740
anche il metodo GET,

85
00:06:26,740 --> 00:06:28,615
il PUT o il metodo POST.

86
00:06:28,615 --> 00:06:35,440
L' azione corrispondente da eseguire sul database se si tratta di una richiesta GET che

87
00:06:35,440 --> 00:06:39,940
causa un metodo di ricerca piatti da eseguire o

88
00:06:39,940 --> 00:06:44,235
una richiesta POST causando un metodo di creazione piatti da eseguire,

89
00:06:44,235 --> 00:06:48,595
dovrà essere eseguita dal nostro server Express con conseguente

90
00:06:48,595 --> 00:06:53,285
operazione corrispondente avviato sul database MongoDB.

91
00:06:53,285 --> 00:06:55,555
Quindi, con questa comprensione di

92
00:06:55,555 --> 00:07:00,655
come le richieste sono tradotte in una corrispondente operazioni di database,

93
00:07:00,655 --> 00:07:06,720
passiamo ai due esercizi in cui vedremo la gestione della

94
00:07:06,720 --> 00:07:15,040
richiesta GET, PUT, POST e DELETE arrivando ai punti finali di/dishId e

95
00:07:15,040 --> 00:07:18,940
anche per modificare specifici commenti che si trovano

96
00:07:18,940 --> 00:07:24,470
nei sottodocumenti racchiusi all'interno del documento piatto.