1
00:00:03,810 --> 00:00:05,895
Dans la conférence précédente,

2
00:00:05,895 --> 00:00:07,880
nous avons appris à propos de l'API REST.

3
00:00:07,880 --> 00:00:10,781
Vous avez vu comment les points de terminaison de l'API REST prennent en

4
00:00:10,781 --> 00:00:14,990
charge un moyen pour une application cliente de récupérer

5
00:00:14,990 --> 00:00:23,100
des données du serveur ou de télécharger des données sur le serveur à l'aide des différentes opérations HTTP.

6
00:00:23,100 --> 00:00:27,062
Dans cette conférence et cet exercice qui suit cette conférence,

7
00:00:27,062 --> 00:00:30,985
nous examinerons spécifiquement le type de support qu'Express

8
00:00:30,985 --> 00:00:36,545
prend en charge pour la conception et l'implémentation d'un serveur basé sur l'API REST.

9
00:00:36,545 --> 00:00:40,085
En particulier, nous allons également examiner le routeur Express,

10
00:00:40,085 --> 00:00:44,600
et comment il nous permet de subdiviser notre application

11
00:00:44,600 --> 00:00:50,285
puis de l'organiser en plusieurs applications de type mini Express,

12
00:00:50,285 --> 00:00:54,495
qui se combinent pour former l'application Express, en

13
00:00:54,495 --> 00:01:00,605
particulier lorsque nous traitons de diverses API REST et pièces.

14
00:01:00,605 --> 00:01:02,985
Donc, pour résumer, dans la conférence précédente,

15
00:01:02,985 --> 00:01:06,315
nous avons examiné REST en détail.

16
00:01:06,315 --> 00:01:10,560
Nous avons également examiné comment chaque point de terminaison est identifié par un URI,

17
00:01:10,560 --> 00:01:13,950
et comment nous pouvons spécifier les différentes opérations à effectuer sur

18
00:01:13,950 --> 00:01:18,295
chaque point de terminaison en utilisant le verbe HTTP approprié,

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

20
00:01:20,880 --> 00:01:22,560
Maintenant, dans cette conférence,

21
00:01:22,560 --> 00:01:29,530
nous allons voir comment Express prend en charge le développement d'un serveur API REST.

22
00:01:29,530 --> 00:01:35,070
Nous examinerons la prise en charge d'Express pour diverses questions telles que app.all,

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

24
00:01:38,335 --> 00:01:43,305
et comment ces méthodes peuvent être utilisées pour construire un serveur API REST.

25
00:01:43,305 --> 00:01:50,104
Dans Express, les différents groupes d'applications peuvent être définis à l'aide de l'application,.

26
00:01:50,104 --> 00:01:51,955
et les différentes méthodes.

27
00:01:51,955 --> 00:01:59,180
Ainsi, l'app.all spécifie une opération qui doit être effectuée sur tous les différents verbes,

28
00:01:59,180 --> 00:02:00,990
sur, dans et partie.

29
00:02:00,990 --> 00:02:04,050
Ainsi, par exemple, dans cet exemple,

30
00:02:04,050 --> 00:02:07,970
nous voyons que le point de terminaison est défini par /plats,

31
00:02:07,970 --> 00:02:13,230
et donc app.all, tout ce qui est spécifié dans la fonction qui est donnée pour app.all,

32
00:02:13,230 --> 00:02:16,830
sera appliqué à toutes les requêtes entrantes.

33
00:02:16,830 --> 00:02:22,155
L' app.get spécifie ce qui doit être fait pour les requêtes GET et, en

34
00:02:22,155 --> 00:02:24,233
conséquence, pour les

35
00:02:24,233 --> 00:02:30,015
requêtes POST, PUT et DELETE qui sont envoyées au point de terminaison /plats,

36
00:02:30,015 --> 00:02:32,700
comme indiqué dans cet exemple.

37
00:02:32,700 --> 00:02:39,471
Express prend également en charge la définition des points de terminaison avec des paramètres.

38
00:02:39,471 --> 00:02:45,750
Ainsi, par exemple, vous pouvez spécifier un ID de plat spécifique si vous le souhaitez,

39
00:02:45,750 --> 00:02:49,500
puis laisser l'opération être effectuée pour

40
00:02:49,500 --> 00:02:55,320
ce point de terminaison spécifique faisant référence à ce plat spécifique avec un ID de plat donné.

41
00:02:55,320 --> 00:02:58,890
Donc, dans ce cas, l'ID plat lui-même est

42
00:02:58,890 --> 00:03:03,706
spécifié en tant que paramètre et le modèle utilisé pour cela est,

43
00:03:03,706 --> 00:03:05,460
comme vous le voyez dans cet exemple,

44
00:03:05,460 --> 00:03:11,920
/dishes/ : et alors vous spécifiez le paramètre ici.

45
00:03:11,920 --> 00:03:14,310
Pour qu'il soit facile pour nous de comprendre,

46
00:03:14,310 --> 00:03:18,060
j'ai nommé le paramètre comme DisHID là-dedans.

47
00:03:18,060 --> 00:03:22,035
Vous pouvez utiliser n'importe quel nom de paramètre que vous choisissez, mais encore

48
00:03:22,035 --> 00:03:27,290
une fois, l'utilisation d'un nom significatif pour un paramètre facilite la compréhension du code.

49
00:03:27,290 --> 00:03:28,815
Donc, dans cet exemple,

50
00:03:28,815 --> 00:03:34,058
le:dishid signifie que si nous émettons une requête à un point de terminaison,

51
00:03:34,058 --> 00:03:38,400
disons par exemple, /dishes/23,

52
00:03:38,400 --> 00:03:45,300
alors le paramètre DishiD nous permet d'extraire ce nombre 23 afin que nous

53
00:03:45,300 --> 00:03:48,420
puissions opérer sur le plat numéro 23 dans

54
00:03:48,420 --> 00:03:52,496
la fonction qui est spécifiée dans cette méthode ici.

55
00:03:52,496 --> 00:03:55,190
Ainsi, là, le paramètre,

56
00:03:55,190 --> 00:04:01,440
le paramètre DisHID lui-même peut être obtenu en utilisant l'objet request sur lequel

57
00:04:01,440 --> 00:04:04,020
la propriété params que vous avez supporté et

58
00:04:04,020 --> 00:04:08,885
la propriété params prend en charge tous les paramètres de requête entrante,

59
00:04:08,885 --> 00:04:10,470
et disHID, en particulier,

60
00:04:10,470 --> 00:04:13,710
est l'un de ces paramètres de requête qui est accessible,

61
00:04:13,710 --> 00:04:16,271
comme indiqué dans le code ici.

62
00:04:16,271 --> 00:04:22,585
Lorsque vous envoyez une requête PUT ou POST du client au serveur,

63
00:04:22,585 --> 00:04:28,545
vous enfermez souvent les données dans le corps du message envoyé au serveur.

64
00:04:28,545 --> 00:04:31,110
Maintenant, ce qui signifie que nous avons besoin d'une méthode pour

65
00:04:31,110 --> 00:04:34,230
extraire des informations du corps du message.

66
00:04:34,230 --> 00:04:39,320
C' est donc là que le middleware de l'analyseur de corps pour Express est très utile.

67
00:04:39,320 --> 00:04:44,805
Ainsi, l'analyseur de corps nous permet d'analyser les informations du corps du message.

68
00:04:44,805 --> 00:04:47,515
Pour utiliser l'analyseur de corps, comme on s'y attendrait,

69
00:04:47,515 --> 00:04:52,155
nous installons le module de noeud d'analyseur de corps,

70
00:04:52,155 --> 00:04:56,070
puis le nécessiterions dans notre application Express,

71
00:04:56,070 --> 00:04:59,550
puis spécifions app.use (BodyParser).

72
00:04:59,550 --> 00:05:03,570
Et si le corps contient des données au format JSON,

73
00:05:03,570 --> 00:05:05,810
vous pouvez dire Bodyparser.json,

74
00:05:05,810 --> 00:05:09,561
ce qui signifie que cela analysera uniquement les données qui sont au

75
00:05:09,561 --> 00:05:14,250
format JSON qui est enfermé dans le corps de ce message de requête.

76
00:05:14,250 --> 00:05:16,145
En particulier, dans l'exercice,

77
00:05:16,145 --> 00:05:22,620
nous analyserons les données entrantes qui sont envoyées sous la forme d'une chaîne JSON.

78
00:05:22,620 --> 00:05:24,930
L' analyseur de corps, comme vous vous y attendez,

79
00:05:24,930 --> 00:05:30,480
analyse le corps du message et remplit la propriété req.body.

80
00:05:30,480 --> 00:05:32,190
Ainsi, sur la requête,

81
00:05:32,190 --> 00:05:36,250
la propriété body contiendra tout ce qui est analysé à partir

82
00:05:36,250 --> 00:05:41,600
du corps du message de requête par l'analyseur de corps.

83
00:05:41,600 --> 00:05:45,030
Si vous implémentez une application Express

84
00:05:45,030 --> 00:05:48,465
qui prend en charge plusieurs points de terminaison de l'API REST,

85
00:05:48,465 --> 00:05:53,265
il est logique de subdiviser le code en

86
00:05:53,265 --> 00:05:59,520
plusieurs modules, puis de les utiliser pour construire l'application Express globale.

87
00:05:59,520 --> 00:06:03,347
Donc, c'est là où le routeur Express vient à notre aide.

88
00:06:03,347 --> 00:06:08,070
Un routeur Express définit de nombreuses applications Express,

89
00:06:08,070 --> 00:06:10,045
et au sein de ces nombreuses applications Express,

90
00:06:10,045 --> 00:06:11,480
vous pouvez, par exemple,

91
00:06:11,480 --> 00:06:16,550
traiter un point de terminaison d'API REST particulier plus en détail,

92
00:06:16,550 --> 00:06:20,215
ou un modèle particulier de point de terminaison d'API REST plus en détail.

93
00:06:20,215 --> 00:06:27,656
Ainsi, par exemple, nous pouvons définir un Dish.Router comme express.Router,

94
00:06:27,656 --> 00:06:32,450
puis le Dish.Router peut alors gérer les points de terminaison.

95
00:06:32,450 --> 00:06:35,420
Donc, lorsque vous exprimez quelque chose comme express.Router,

96
00:06:35,420 --> 00:06:38,570
il prend en charge le point de terminaison de route.

97
00:06:38,570 --> 00:06:41,015
L' une des raisons de l'utilisation du routeur Express,

98
00:06:41,015 --> 00:06:42,455
comme vous le savez,

99
00:06:42,455 --> 00:06:45,470
est que si nous utilisons les

100
00:06:45,470 --> 00:06:47,142
méthodes standard GET, PUT, POST et DELETE,

101
00:06:47,142 --> 00:06:48,760
pour chacune de ces méthodes,

102
00:06:48,760 --> 00:06:52,315
vous devez spécifier explicitement les points de terminaison de l'API REST.

103
00:06:52,315 --> 00:06:55,130
Un avantage de l'utilisation du routeur Express est que si vous

104
00:06:55,130 --> 00:06:59,422
dites le router.route, puis spécifiez le point de terminaison,

105
00:06:59,422 --> 00:07:07,220
ce point de terminaison sera appliqué à toutes les méthodes et toutes les différentes

106
00:07:07,220 --> 00:07:11,060
méthodes liées au verbe GET, PUT, POST et DELETE peuvent toutes être enchaînées

107
00:07:11,060 --> 00:07:16,575
ensemble dans la route en définissant le code pour notre application.

108
00:07:16,575 --> 00:07:22,075
Nous examinerons plus de détails à ce sujet dans l'exercice qui suit cette conférence.

109
00:07:22,075 --> 00:07:27,505
Avec cette compréhension rapide de la façon dont Express prend en charge le point de terminaison de l'API REST,

110
00:07:27,505 --> 00:07:31,070
passons à l'exercice où nous allons construire

111
00:07:31,070 --> 00:07:35,682
leur prise en charge pour le point de terminaison de l'API REST /plats. Dans le

112
00:07:35,682 --> 00:07:38,180
cadre de la première affectation,

113
00:07:38,180 --> 00:07:40,160
vous allez étendre

114
00:07:40,160 --> 00:07:44,559
cette application Express pour prendre en charge des points de terminaison d'API REST supplémentaires,

115
00:07:44,559 --> 00:07:48,990
y compris /promotions et /leaders.

116
00:07:48,990 --> 00:07:52,040
Si vous avez suivi les cours précédents dans la spécialisation,

117
00:07:52,040 --> 00:07:55,220
vous commencerez immédiatement à voir pourquoi nous prenons en charge

118
00:07:55,220 --> 00:08:00,810
tous ces différents points de terminaison API REST sur un autre côté serveur.