1
00:00:00,000 --> 00:00:04,528
[MUSIC]

2
00:00:04,528 --> 00:00:09,392
Теперь, когда мы поняли REST API и выражаем поддержку

3
00:00:09,392 --> 00:00:13,293
REST API, давайте перейдем к следующему упражнению.

4
00:00:13,293 --> 00:00:17,168
Где мы рассмотрим, как мы будем развивать REST API,

5
00:00:17,168 --> 00:00:19,972
используя поддержку, предоставленную express.

6
00:00:19,972 --> 00:00:23,110
А также использование экспресс-маршрутизатора, что

7
00:00:23,110 --> 00:00:28,110
позволяет нам организовать наш код таким образом, который более подходит,

8
00:00:28,110 --> 00:00:33,231
когда вам нужно поддерживать большое количество конечных точек REST API.

9
00:00:35,080 --> 00:00:39,965
Чтобы начать работу, продолжая работу с папкой node-express,

10
00:00:39,965 --> 00:00:44,565
мы работаем над веб-сервером на основе экспресс.

11
00:00:44,565 --> 00:00:50,546
В подсказке, давайте установим body-парсер,

12
00:00:50,546 --> 00:00:57,729
поэтому для этого введите npm install body-parser —save.

13
00:00:57,729 --> 00:01:02,674
И мы используем версию 1.18.3

14
00:01:02,674 --> 00:01:06,689
body-parser в этом курсе здесь.

15
00:01:06,689 --> 00:01:12,151
Теперь, как только мы установили body-парсер, затем войдем в наш код.

16
00:01:12,151 --> 00:01:16,476
В index.js5

17
00:01:16,476 --> 00:01:22,723
позвольте мне потребовать BodyParser, поэтому

18
00:01:22,723 --> 00:01:28,492
мы скажем, const BodyParser

19
00:01:28,492 --> 00:01:33,553
требует body-парсер.

20
00:01:33,553 --> 00:01:39,891
И тогда всякий раз, когда вам нужно использовать промежуточное программное обеспечение,

21
00:01:39,891 --> 00:01:46,558
вы скажете, app.use (BodyParser.json).

22
00:01:46,558 --> 00:01:51,782
Таким образом, это позволяет анализировать тело сообщения запроса,

23
00:01:51,782 --> 00:01:54,989
которое отформатировано в формате JSON.

24
00:01:57,466 --> 00:02:03,374
Как только мы завершим это, давайте начнем

25
00:02:03,374 --> 00:02:08,678
создавать поддержку REST API для конечной точки /dishes.

26
00:02:08,678 --> 00:02:12,797
Использование

27
00:02:12,797 --> 00:02:16,339
методов app.all, app.get, put, post и delete поддерживаются экспресс-.

28
00:02:16,339 --> 00:02:21,692
Поэтому, чтобы сделать это, позвольте мне начать с выражения

29
00:02:21,692 --> 00:02:26,725
app.all, и первые параметры,

30
00:02:26,725 --> 00:02:31,937
которые принимает app.all, - это конечная точка.

31
00:02:31,937 --> 00:02:36,360
Поэтому в этом случае я указываю конечную точку /dishes.

32
00:02:36,360 --> 00:02:43,560
И тогда вторым параметром является функция обратного вызова,

33
00:02:43,560 --> 00:02:49,564
req, res, далее, три параметра здесь.

34
00:02:49,564 --> 00:02:56,518
И внутри этой функции обратного вызова мы будем обрабатывать входящий запрос.

35
00:02:56,518 --> 00:03:01,740
Так что мы скажем, когда поступит запрос, для всех запросов.

36
00:03:01,740 --> 00:03:06,993
Поэтому, когда мы говорим app.all, независимо от того, какой метод вызывается,

37
00:03:06,993 --> 00:03:12,864
get, put, post или delete, для конечной точки /dishes REST API

38
00:03:12,864 --> 00:03:17,190
этот код будет выполняться первым по умолчанию здесь.

39
00:03:17,190 --> 00:03:26,376
Таким образом, мы скажем, res StatusCode 200, а

40
00:03:26,376 --> 00:03:31,889
затем res.SetHeader и

41
00:03:31,889 --> 00:03:39,248
скажем Content-Type текст.

42
00:03:39,248 --> 00:03:44,290
Теперь мы отправим простой текст, вместо HTML-текста.

43
00:03:44,290 --> 00:03:47,575
Этого должно быть достаточно для конечных точек REST API.

44
00:03:47,575 --> 00:03:52,420
Позже мы отправим данные в виде JSON, как только

45
00:03:52,420 --> 00:03:54,640
мы сможем получить данные из базы данных.

46
00:03:54,640 --> 00:03:57,340
Так что придет в одном из последующих упражнений.

47
00:03:57,340 --> 00:04:04,389
На данный момент мы просто отправим ответы в открытый текст обратно клиенту.

48
00:04:04,389 --> 00:04:10,785
Теперь после этих двух промежуточное программное обеспечение здесь еще не завершено.

49
00:04:10,785 --> 00:04:17,590
Таким образом, мы будем вызывать следующую функцию здесь, так что следующая, как вы видите, относится к этой следующей.

50
00:04:17,590 --> 00:04:24,954
Поэтому, когда вы позвоните дальше, это означает, что он будет продолжать искать

51
00:04:24,954 --> 00:04:29,665
дополнительные спецификации ниже здесь,

52
00:04:29,665 --> 00:04:33,790
которые будут соответствовать этой конечной точке блюд.

53
00:04:33,790 --> 00:04:38,282
Таким образом, это будет сделано для всех запросов, получить, положить, опубликовать и

54
00:04:38,282 --> 00:04:42,712
удалить, на посуду, и это будет продолжаться до следующего.

55
00:04:42,712 --> 00:04:48,436
Итак, предположим, что мы получим запрос

56
00:04:48,436 --> 00:04:53,792
на блюда,

57
00:04:53,792 --> 00:04:58,961
а это означает, что теперь, если мы получим запрос на блюда,

58
00:04:58,961 --> 00:05:04,133
сначала это будет выполнено,

59
00:05:04,133 --> 00:05:09,304
а затем req и res будут

60
00:05:09,304 --> 00:05:13,760
переданы на этот второй вызов здесь.

61
00:05:13,760 --> 00:05:17,481
Так что в этом случае мне больше не нужен следующий,

62
00:05:17,481 --> 00:05:21,335
потому что я не собираюсь звонить дальше.

63
00:05:21,335 --> 00:05:26,444
Я закончу обработку прямо в этом методе.

64
00:05:26,444 --> 00:05:31,337
Поэтому, если мы изменим req или res внутри этого кода,

65
00:05:31,337 --> 00:05:36,607
то при вызове следующего, этот модифицированный объект

66
00:05:36,607 --> 00:05:41,130
будет передан в качестве параметра этому.

67
00:05:41,130 --> 00:05:45,698
Поэтому, если вы выдали запрос get на блюда, так что это то, что будет

68
00:05:45,698 --> 00:05:50,202
выполнено сразу после этого, так что следующее приведет к его передаче.

69
00:05:50,202 --> 00:05:55,836
И тут, вы заметили, что мы изменили объект res здесь.

70
00:05:55,836 --> 00:06:02,770
И модификация будет нести в качестве входного параметра этой функции здесь.

71
00:06:03,940 --> 00:06:09,380
Так что внутри этой функции get мы можем сказать, например, на данный момент,

72
00:06:09,380 --> 00:06:15,197
я просто собираюсь отправить обратно простое сообщение, скажем,

73
00:06:15,197 --> 00:06:20,170
пошлю все блюда вам.

74
00:06:20,170 --> 00:06:25,650
Позже, когда мы извлекаем информацию о блюдах из базы данных

75
00:06:25,650 --> 00:06:31,036
после того, как мы узнаем о MongoDB, эта функция будет возвращать

76
00:06:31,036 --> 00:06:36,534
данные JSON обратно клиенту, так как он находится в запросе get здесь.

77
00:06:36,534 --> 00:06:40,566
Теперь в предыдущем курсе мы использовали JSON-сервер, и

78
00:06:40,566 --> 00:06:44,457
сервер JSON уже предоставлял нам все это.

79
00:06:44,457 --> 00:06:46,965
Теперь вы видите, как вы

80
00:06:46,965 --> 00:06:50,268
построили реальный сервер, который будет обрабатывать входящий запрос.

81
00:06:50,268 --> 00:06:53,139
А затем сгенерировать соответствующий ответ и

82
00:06:53,139 --> 00:06:57,857
отправить его обратно вам в ответ на запрос, полученный со стороны клиента.

83
00:06:57,857 --> 00:07:02,611
И вот где пользователь экспресс, как мы видим здесь, полезен.

84
00:07:02,611 --> 00:07:06,971
Таким образом, мы справились получить,

85
00:07:06,971 --> 00:07:14,387
давайте обрабатывать пост также на посуду здесь.

86
00:07:16,120 --> 00:07:21,064
И снова параметры будут (req, res,

87
00:07:21,064 --> 00:07:26,722
next), и эта функция, которая вызывается, будет здесь.

88
00:07:26,722 --> 00:07:31,606
Теперь, когда получен запрос get, потому что здесь вы вызываете rest.end.

89
00:07:31,606 --> 00:07:36,982
Таким образом, этот конец - это обработка запроса get и не вызывает ответ,

90
00:07:36,982 --> 00:07:42,130
который будет отправлен обратно, или ответ, который будет отправлен обратно клиенту в этот момент.

91
00:07:42,130 --> 00:07:47,050
Теперь, если вы получите почтовый запрос на блюда, опять же, весь этот код будет выполнен.

92
00:07:47,050 --> 00:07:52,859
И затем, из-за этого следующего, это упадет в этот вызов функции здесь.

93
00:07:52,859 --> 00:07:57,000
И тогда код здесь, будет выполнен, поэтому при получении сообщения Почтовый

94
00:07:59,610 --> 00:08:04,820
запрос, поступающий с сервера, будет нести некоторую информацию

95
00:08:04,820 --> 00:08:08,710
в теле сообщения в виде данных JSON.

96
00:08:08,710 --> 00:08:13,650
Они увидят, какая форма данных JSON, когда мы

97
00:08:13,650 --> 00:08:18,910
посмотрим позже, когда мы тестируем конечную точку с помощью post net.

98
00:08:18,910 --> 00:08:24,700
Я покажу вам, что будет содержать тело сообщения о почтовом запросе.

99
00:08:24,700 --> 00:08:27,710
Но в этот момент я собираюсь сделать,

100
00:08:27,710 --> 00:08:33,420
я извлечу информацию из тела.

101
00:08:33,420 --> 00:08:38,545
И поэтому, когда мы используем парсер тела, происходит то, что для

102
00:08:38,545 --> 00:08:44,541
входящего запроса тело входящего запроса будет проанализировано, а

103
00:08:44,541 --> 00:08:48,237
затем добавлено в объект req как req.body.

104
00:08:48,237 --> 00:08:52,843
Таким образом, req.body даст вам доступ к всему, что находится внутри этого тела

105
00:08:52,843 --> 00:08:54,050
сообщения.

106
00:08:54,050 --> 00:08:58,642
Поэтому, когда я отправлю запрос,

107
00:08:58,642 --> 00:09:04,339
я добавлю информацию в

108
00:09:04,339 --> 00:09:10,034
тело запроса в виде строки JSON,

109
00:09:10,034 --> 00:09:15,570
которая содержит имя и описание.

110
00:09:15,570 --> 00:09:20,081
Поэтому я собираюсь извлечь эти две части информации, а

111
00:09:20,081 --> 00:09:26,080
затем распечатать их, а затем отправить их обратно клиенту в ответном сообщении.

112
00:09:26,080 --> 00:09:32,840
Так что я могу сказать, req.body.а затем имя.

113
00:09:32,840 --> 00:09:38,298
И поэтому ожидание заключается в том, что когда клиент отправляет сообщение,

114
00:09:38,298 --> 00:09:42,183
тело сообщения будет содержать строку JSON,

115
00:09:42,183 --> 00:09:47,108
которая также будет содержать свойство name в строке JSON.

116
00:09:47,108 --> 00:09:52,646
Итак, req.body.name plus, и

117
00:09:52,646 --> 00:09:57,952
это то, где я буду включать

118
00:09:57,952 --> 00:10:06,970
детали: + req.body.description.

119
00:10:06,970 --> 00:10:11,654
Таким образом, независимо от того, что строка

120
00:10:11,654 --> 00:10:15,963
JSON содержит в req.body, но строка JSON будет проанализирована

121
00:10:15,963 --> 00:10:19,909
в объект JavaScript и добавлена в объект запроса в качестве тела свойства.

122
00:10:19,909 --> 00:10:22,971
Объект JavaScript указывает на то, что

123
00:10:22,971 --> 00:10:27,440
пришло в виде строки JSON в теле сообщения запроса.

124
00:10:27,440 --> 00:10:31,750
Поэтому я могу разобрать свойство name, свойство description,

125
00:10:31,750 --> 00:10:38,000
вы можете иметь свойство цены, свойство изображения и все это.

126
00:10:38,000 --> 00:10:42,260
Поэтому, если вы взяли предыдущий курс, вы видели структуру

127
00:10:42,260 --> 00:10:48,850
объекта блюда в виде строки JSON или объекта JavaScript там.

128
00:10:48,850 --> 00:10:52,920
Итак, имя и описание звучит знакомо вам.

129
00:10:52,920 --> 00:10:55,400
Так что именно то, что я использую здесь.

130
00:10:55,400 --> 00:11:00,823
Сейчас я только извлекаю имя и описание из тела, а

131
00:11:00,823 --> 00:11:04,220
затем отправляю его обратно клиенту в этом теле.

132
00:11:04,220 --> 00:11:09,460
Поэтому я просто создаю это ответное сообщение здесь, используя информацию

133
00:11:09,460 --> 00:11:13,150
из тела сообщения запроса, а затем отправляю его обратно клиенту.

134
00:11:13,150 --> 00:11:17,830
Таким образом, я могу подтвердить, что сервер получает все, что я отправляю

135
00:11:17,830 --> 00:11:19,930
в теле сообщения.

136
00:11:19,930 --> 00:11:21,820
Так что это почтовый запрос.

137
00:11:23,390 --> 00:11:30,620
Теперь, чтобы положить, позвольте мне просто скопировать это, а затем вставить его здесь.

138
00:11:30,620 --> 00:11:35,360
А затем для надевания, что блюда конечной точки,

139
00:11:35,360 --> 00:11:39,100
потому что он положить на блюда конечной точки не имеет смысла.

140
00:11:39,100 --> 00:11:44,440
Сообщение означает, что вы размещаете новое блюдо на серверах.

141
00:11:44,440 --> 00:11:50,992
Положить на конечную точку посуды не имеет смысла,

142
00:11:50,992 --> 00:11:55,516
поэтому здесь, что я собираюсь сделать, я

143
00:11:55,516 --> 00:12:00,664
собираюсь ответить обратно с помощью

144
00:12:00,664 --> 00:12:06,660
операции PUT, не поддерживаемой /dishes.

145
00:12:06,660 --> 00:12:14,790
Кроме того, я также, Включите код состояния 403.

146
00:12:14,790 --> 00:12:19,987
403 означает, что их работа не поддерживается.

147
00:12:19,987 --> 00:12:24,319
Поэтому, если вы оглянетесь на таблицу кодов ответа HTTP,

148
00:12:24,319 --> 00:12:30,600
вы увидите соответствующий код 403, что он представляет там.

149
00:12:30,600 --> 00:12:34,650
Так что это то, что я использую для публикации.

150
00:12:34,650 --> 00:12:39,879
Для удаления я собираюсь скопировать

151
00:12:39,879 --> 00:12:44,777
это, а для удаления я собираюсь,

152
00:12:47,537 --> 00:12:55,960
Просто разобрать это, а затем мы скажем, Удаление всех блюд.

153
00:12:55,960 --> 00:13:02,200
Поэтому, когда вы отправляете запрос на удаление на этой конечной точке /dishes.

154
00:13:02,200 --> 00:13:04,900
Это означает, что

155
00:13:04,900 --> 00:13:08,960
клиент хочет удалить всю информацию о блюдах на стороне сервера.

156
00:13:08,960 --> 00:13:11,300
Теперь это опасная операция, поэтому

157
00:13:11,300 --> 00:13:15,540
вы убедитесь, что вы не разрешаете партнерским пользователям делать это.

158
00:13:15,540 --> 00:13:17,750
Поэтому позже, когда мы изучаем аутентификацию,

159
00:13:17,750 --> 00:13:23,220
мы увидим, как мы можем проверить эту операцию только привилегированным пользователям.

160
00:13:23,220 --> 00:13:28,620
Но опять же, как видите, это опасная операция, так что имейте в виду это.

161
00:13:28,620 --> 00:13:33,340
Итак, теперь вы видите, что в конечной точке блюд мы получаем, ставим, размещаем

162
00:13:33,340 --> 00:13:35,130
и удаляем поддержку.

163
00:13:35,130 --> 00:13:41,520
Давайте также поддержим это на блюде/:Dishid конечной точки.

164
00:13:41,520 --> 00:13:46,280
Поэтому я собираюсь скопировать методы get, put, post и delete отсюда,

165
00:13:48,530 --> 00:13:54,175
а затем вызывает все их также, чтобы поддерживаться на

166
00:13:54,175 --> 00:14:00,360
блюде/:dishid.

167
00:14:00,360 --> 00:14:06,913
Так что это для получения, и мы копируем это и

168
00:14:06,913 --> 00:14:11,480
публикуем, помещаем и удаляем.

169
00:14:11,480 --> 00:14:13,330
Как мы справимся с каждым из них?

170
00:14:13,330 --> 00:14:19,460
Поэтому для получения, если я получаю запрос на тарелки/Dishid,

171
00:14:19,460 --> 00:14:22,750
то, что я хотел бы сделать, это извлечь этот параметр, а

172
00:14:22,750 --> 00:14:27,000
затем отправить его обратно в запрос, в ответном сообщении.

173
00:14:27,000 --> 00:14:29,725
Так что мы скажем, мы отправим,

174
00:14:39,018 --> 00:14:41,625
Детали блюда.

175
00:14:44,584 --> 00:14:46,910
Теперь какое блюдо?

176
00:14:46,910 --> 00:14:51,570
Эта информация находится в параметре.

177
00:14:51,570 --> 00:14:55,335
Таким образом, это значение параметра может получить из

178
00:14:55,335 --> 00:15:02,300
req.params.dishid.

179
00:15:02,300 --> 00:15:07,510
Таким образом, этот diShid, как вы видите, имя, которое вы используете здесь, должно соответствовать этому значению здесь.

180
00:15:07,510 --> 00:15:09,370
Поэтому, если вы просто видите идентификатор здесь,

181
00:15:09,370 --> 00:15:13,220
это также должно соответствовать данному SID здесь.

182
00:15:13,220 --> 00:15:17,920
Таким образом, само имя ничего не значит, за исключением того, что это имя параметра и

183
00:15:17,920 --> 00:15:23,400
это должно совпадать друг с другом, так что вы можете получить информацию правильно.

184
00:15:25,090 --> 00:15:30,470
Так что скажем, пришлите параметры тарелки DishID, а

185
00:15:30,470 --> 00:15:37,360
потом мы вам скажем.

186
00:15:37,360 --> 00:15:43,160
Таким образом, мы знаем, что сервер получает параметр блюда..

187
00:15:43,160 --> 00:15:47,350
Так что если я скажу /dishes/23 там несколько ответов

188
00:15:47,350 --> 00:15:52,350
присылают детали блюда 23 вам и так далее.

189
00:15:52,350 --> 00:15:57,632
Таким образом, мы увидим, как это работает, когда мы используем пост для тестирования этого сервера.

190
00:15:57,632 --> 00:15:59,584
Теперь на пост.

191
00:15:59,584 --> 00:16:03,530
Для сообщения этот метод не будет поддерживаться,

192
00:16:03,530 --> 00:16:07,060
поэтому я просто собираюсь скопировать эту часть.

193
00:16:07,060 --> 00:16:12,205
не имеет смысла делать сообщение на определенном идентификаторе блюда,

194
00:16:12,205 --> 00:16:16,375
потому что вы не пытаетесь добавить новое блюдо.

195
00:16:16,375 --> 00:16:21,360
Но вы хотите изменить, и модификация выполняется с помощью операции ввода.

196
00:16:21,360 --> 00:16:28,111
Таким образом, скажем, операция POST не поддерживается на /dishes.

197
00:16:33,331 --> 00:16:36,360
И тогда я собираюсь добавить в.

198
00:16:39,750 --> 00:16:43,197
Рек.парам.Дишид.

199
00:16:43,197 --> 00:16:47,535
Таким образом, это отправит обратно сообщение, не поддерживаемое на

200
00:16:47,535 --> 00:16:50,752
блюде/23 в ответном сообщении.

201
00:16:50,752 --> 00:16:55,926
Теперь, для PUT, для PUT, мы скажем,

202
00:16:59,902 --> 00:17:08,799
res.end и скажем Уилл, обновить блюдо.

203
00:17:13,902 --> 00:17:20,978
Рек.парам.Дишид.

204
00:17:28,915 --> 00:17:31,675
Вернее, мы сделаем это таким образом.

205
00:17:33,785 --> 00:17:39,141
Сначала я напишу, поэтому

206
00:17:39,141 --> 00:17:45,345
res.write можно использовать для добавления строки в ответное сообщение.

207
00:17:45,345 --> 00:17:50,077
Так что скажем, обновление блюда.

208
00:17:50,077 --> 00:17:58,655
И мы скажем req.params.dishid.

209
00:17:58,655 --> 00:18:06,245
И поскольку это операция PUT, и если тело содержит строку JSON,

210
00:18:06,245 --> 00:18:10,277
которая содержит детали блюда,

211
00:18:10,277 --> 00:18:17,310
я могу извлечь строку JSON, потому что мы используем анализатор тела.

212
00:18:17,310 --> 00:18:21,649
Так что мы скажем, будет

213
00:18:21,649 --> 00:18:26,569
обновлять блюдо:.

214
00:18:30,234 --> 00:18:31,924
Какое блюдо?

215
00:18:31,924 --> 00:18:34,822
req.body.name.

216
00:18:38,122 --> 00:18:38,657
Плюс.

217
00:18:40,531 --> 00:18:45,701
С подробностями,

218
00:18:45,701 --> 00:18:55,250
req.body.description.

219
00:18:59,320 --> 00:19:08,800
Теперь, когда мы обновляем блюдо, я хочу добавить, Новая строка там.

220
00:19:08,800 --> 00:19:11,411
Так что я скажу «/n» там.

221
00:19:14,500 --> 00:19:19,257
Поэтому, когда вы делаете PUT, вы отправляете обратно информацию о том, какой идентификатор блюда вы

222
00:19:19,257 --> 00:19:22,674
обновляете, а также детали, которые вы обновляете.

223
00:19:22,674 --> 00:19:26,997
Имя и описание,

224
00:19:26,997 --> 00:19:34,318
которое должно быть в теле сообщения PUT.

225
00:19:34,318 --> 00:19:41,868
Для удаления, Это будет сказать Удаление блюдо, и req.params.dishid.

226
00:19:41,868 --> 00:19:47,970
И поэтому для удаления, это операция, которая будет выполнена.

227
00:19:47,970 --> 00:19:51,607
Таким образом, вы видите, что теперь у нас есть

228
00:19:51,607 --> 00:19:55,838
операции get, put, post и delete на диске/dishid, конечной точке, а

229
00:19:55,838 --> 00:20:00,590
также операции get, put, post на /dishes, конечной точке.

230
00:20:00,590 --> 00:20:03,765
Итак, давайте сохраним изменения.

231
00:20:03,765 --> 00:20:05,387
И снова запустите наш сервер.

232
00:20:08,245 --> 00:20:10,643
Запустите сервер, сказав npm start.

233
00:20:10,643 --> 00:20:15,611
Давайте теперь перейдем к почтальну и отправим несколько запросов на этот сервер и

234
00:20:15,611 --> 00:20:17,270
посмотрим, что он возвращает.

235
00:20:17,270 --> 00:20:22,287
Позвольте мне сначала получить доступ к локальному хосту 3000 и посмотреть, что он возвращает.

236
00:20:22,287 --> 00:20:26,832
Поэтому, когда вы отправляете запрос на получение локального хоста 3000,

237
00:20:26,832 --> 00:20:30,798
он все еще возвращает HTML-страницу запуска индекса,

238
00:20:30,798 --> 00:20:35,069
потому что статическая обработка файлов все еще на месте.

239
00:20:35,069 --> 00:20:41,564
Теперь позвольте мне отправить запрос на localhost: 3000/блюда, и это,

240
00:20:41,564 --> 00:20:48,383
как вы ожидаете, отправит обратно ответ, говорящий, что мы вышлем все блюда вам.

241
00:20:48,383 --> 00:20:56,350
Теперь давайте отправим запрос POST на локальный хост: 3000/блюда.

242
00:20:56,350 --> 00:21:01,200
Таким образом, здесь вы можете изменить различные методы, которые вы хотите выполнить.

243
00:21:01,200 --> 00:21:02,880
Но когда вы отправляете сообщение,

244
00:21:02,880 --> 00:21:08,570
вы хотите включить некоторые детали в тело сообщения, потому что

245
00:21:08,570 --> 00:21:12,920
кто-то ожидает, что вы отправите информацию в тело сообщения.

246
00:21:12,920 --> 00:21:17,967
Поэтому нажмите на тело здесь и нажмите на сырую здесь.

247
00:21:17,967 --> 00:21:23,395
И затем, для текста, вы выбираете это в JSON, поэтому

248
00:21:23,395 --> 00:21:26,377
используйте приложение JSON.

249
00:21:26,377 --> 00:21:31,081
Таким образом, тип содержимого будет приложением/JSON

250
00:21:31,081 --> 00:21:34,220
в запросе, который вы отправляете.

251
00:21:34,220 --> 00:21:38,658
Поэтому, поскольку это объект JSON, поэтому

252
00:21:38,658 --> 00:21:43,103
в фигурных скобках я скажу имя.

253
00:21:45,320 --> 00:21:50,727
Я просто напечатаю тест

254
00:21:50,727 --> 00:21:53,939
и описание.

255
00:22:01,212 --> 00:22:05,760
Некоторая стандартная информация здесь, поэтому вы видите, что это строка JSON, которая

256
00:22:05,760 --> 00:22:10,900
содержит два свойства, имя и описание и соответствующие значения.

257
00:22:10,900 --> 00:22:13,858
Итак, давайте отправим почтовый запрос на сервер.

258
00:22:13,858 --> 00:22:18,294
При отправке почтового запроса на сервер, как вы видите,

259
00:22:18,294 --> 00:22:24,290
в ответе говорится, что добавит блюдо: тест недели подробности: описание.

260
00:22:24,290 --> 00:22:30,368
Таким образом, как вы можете видеть, две части информации извлекаются

261
00:22:30,368 --> 00:22:35,772
из тела этого JSON запрошенного [INAUDIBLE], а затем включаются в ответ.

262
00:22:35,772 --> 00:22:39,459
Давайте отправим запрос на посуду.

263
00:22:39,459 --> 00:22:43,029
Когда вы отправляете запрос put в блюда, как вы видите,

264
00:22:43,029 --> 00:22:48,654
он говорит, что операция PUT не поддерживается /fishes, и посмотрите на статус здесь.

265
00:22:48,654 --> 00:22:52,580
Здесь написано «Статус: 403 Запрещено».

266
00:22:52,580 --> 00:22:57,570
Таким образом, эта операция не разрешена на этой конечной точке.

267
00:22:57,570 --> 00:23:01,430
Давайте сделаем операцию DELETE на посуду.

268
00:23:01,430 --> 00:23:04,240
Когда вы DELETE операции на посуду,

269
00:23:04,240 --> 00:23:09,270
то вы заметите, что он говорит удаление всех блюд.

270
00:23:09,270 --> 00:23:11,560
Так вот ответ, который вы получите.

271
00:23:12,920 --> 00:23:15,410
Таким образом, вы видите, что get post, put и

272
00:23:15,410 --> 00:23:20,610
delete в конечной точке /dishes работает так, как вы ожидаете.

273
00:23:20,610 --> 00:23:24,507
Теперь давайте займемся посудой /23.

274
00:23:24,507 --> 00:23:29,017
Итак, 23 вот параметр,

275
00:23:29,017 --> 00:23:34,710
идентификатор блюда, которое вы хотите получить.

276
00:23:34,710 --> 00:23:38,716
Поэтому, когда вы отправляете запрос на то, что сервер

277
00:23:38,716 --> 00:23:41,878
ответит, вышлет вам детали блюда: 23.

278
00:23:41,878 --> 00:23:47,421
Таким образом, вы видите, что параметр был извлечен из сообщения запроса, а

279
00:23:47,421 --> 00:23:50,645
затем включен в ответное сообщение.

280
00:23:50,645 --> 00:23:54,850
Давайте сделаем сообщение об этом.

281
00:23:54,850 --> 00:23:59,580
И, как вы знаете, POST запрещен на этой конечной точке, и

282
00:23:59,580 --> 00:24:03,450
поэтому вы получаете статус 403 Запрещен на этом.

283
00:24:03,450 --> 00:24:05,728
Давайте сделаем операцию PUT на этом.

284
00:24:05,728 --> 00:24:10,040
Поэтому для операции PUT вы заметили, что тело все еще содержит это.

285
00:24:10,040 --> 00:24:13,950
Поэтому в POST, когда вы вводите значение здесь,

286
00:24:13,950 --> 00:24:18,720
оно будет сохранено и может быть включено в другие запросы, которые вы отправляете.

287
00:24:18,720 --> 00:24:25,087
Поэтому, когда вы отправляете запрос PUT на конечную точку, тарелки/23.

288
00:24:25,087 --> 00:24:28,650
Итак, вы заметили, что здесь написано обновление блюда, 23.

289
00:24:28,650 --> 00:24:31,780
Обновите блюдо, название блюда,

290
00:24:31,780 --> 00:24:36,200
с подробностями, описание блюда здесь.

291
00:24:36,200 --> 00:24:41,130
И затем, давайте сделаем операцию удаления на этой конечной точке

292
00:24:41,130 --> 00:24:45,140
, а затем он говорит: d удаление тарелки: 23.

293
00:24:45,140 --> 00:24:52,210
Таким образом, все эти конечные точки поддерживаются, как вы видите в этом примере.

294
00:24:52,210 --> 00:24:58,430
Таким образом, мы выполнили операции PUT, POSRT и удаления как в конечной точке

295
00:24:58,430 --> 00:25:03,830
/dishes, так и в конечной точке идентификатора блюда.

296
00:25:03,830 --> 00:25:08,010
Итак, вы видите, как мы реализовали поддержку конечных точек REST API для

297
00:25:08,010 --> 00:25:12,730
одного набора конечных точек REST API.

298
00:25:12,730 --> 00:25:17,405
Теперь, с этим, мы завершаем первую часть этого упражнения.

299
00:25:17,405 --> 00:25:22,378
Итак, здесь мы видели, как мы можем использовать express для построения и

300
00:25:22,378 --> 00:25:26,755
реализации конечной точки REST API для блюд.

301
00:25:26,755 --> 00:25:27,885
Теперь это хорошее время для

302
00:25:27,885 --> 00:25:32,895
вас сделать git фиксацию с сообщением Express Simple REST.

303
00:25:33,895 --> 00:25:42,361
В соответствии с терминалом я начну, Сервер.

304
00:25:42,361 --> 00:25:45,845
Убедитесь, что три элемента были изменены.

305
00:25:45,845 --> 00:25:52,527
Итак, git add, git commit -m,

306
00:25:52,527 --> 00:26:01,750
Express Simple REST и проверьте набор.

307
00:26:01,750 --> 00:26:08,670
Таким образом, как вы можете видеть, с помощью Express вы можете легко реализовать поддержку REST API.

308
00:26:08,670 --> 00:26:15,300
И, как вы можете видеть из этого списка, вы создаете

309
00:26:15,300 --> 00:26:21,590
методы приложения get, PUT, POST и удаления для всех конечных точек REST API, подобных этому.

310
00:26:21,590 --> 00:26:24,601
Теперь представьте, что у вас есть тысяча конечных точек REST API,

311
00:26:24,601 --> 00:26:27,347
и вам нужно построить что-то вроде этого.

312
00:26:27,347 --> 00:26:33,344
Ваш файл index.js будет взорваться с таким количеством различных конечных точек REST API.

313
00:26:33,344 --> 00:26:37,744
И каждый из них обрабатывается с помощью собственного app.get,

314
00:26:37,744 --> 00:26:41,536
app.put, app.delete и app.post.

315
00:26:41,536 --> 00:26:46,336
Теперь Wxpress поддерживает способ разделения этой работы на несколько,

316
00:26:46,336 --> 00:26:48,442
много приложений Express,

317
00:26:48,442 --> 00:26:54,580
которые затем могут быть объединены вместе, чтобы сформировать общее, Express приложение.

318
00:26:54,580 --> 00:26:58,260
Здесь мы будем использовать Express Router,

319
00:26:58,260 --> 00:27:01,960
чтобы иметь возможность построить мини-Express приложение.

320
00:27:01,960 --> 00:27:06,070
И затем, внутри файла Express Router,

321
00:27:06,070 --> 00:27:10,040
мы будем поддерживать конечную точку REST API для одной группы частей REST API.

322
00:27:10,040 --> 00:27:13,190
Так, например, для посуды и посуды DisHID,

323
00:27:13,190 --> 00:27:15,598
все они могут поддерживаться в одном файле.

324
00:27:15,598 --> 00:27:20,694
Аналогичным образом, в задании вы будете поддерживать

325
00:27:20,694 --> 00:27:25,339
конечную точку REST API, называемую промо-акции и промо-акции.

326
00:27:25,339 --> 00:27:29,570
А затем вы поддержите другой REST API и

327
00:27:29,570 --> 00:27:34,241
для лидеров и /лидеров: LeaderID.

328
00:27:34,241 --> 00:27:39,088
Таким образом, каждая из этих групп может быть реализована отдельно, как и многие

329
00:27:39,088 --> 00:27:43,120
Express приложения, использующие Express Router.

330
00:27:43,120 --> 00:27:46,230
Вот что я проиллюстрирую вам для

331
00:27:46,230 --> 00:27:52,150
конечной точки блюд в следующей части этого упражнения.

332
00:27:52,150 --> 00:27:57,668
Поэтому для этого мы понимаем, что если мы поместим все файлы в одну папку,

333
00:27:57,668 --> 00:28:01,498
то опять же ваша структура папок будет выглядеть грязной.

334
00:28:01,498 --> 00:28:07,731
Поэтому мое предпочтение - создать папку здесь с именами маршрутов.

335
00:28:07,731 --> 00:28:12,591
И эта папка маршрутов будет содержать все маршрутизаторы, которые я собираюсь

336
00:28:12,591 --> 00:28:15,450
создать с помощью экспресс-маршрутизатора.

337
00:28:15,450 --> 00:28:19,465
Поэтому в папке маршрутов я собираюсь создать новый файл под названием

338
00:28:19,465 --> 00:28:27,270
dishRouter.js.

339
00:28:27,270 --> 00:28:31,332
И этот файл dishRouter.js будет содержать

340
00:28:31,332 --> 00:28:36,972
реализацию обработки конечной точки REST API для

341
00:28:36,972 --> 00:28:41,281
/bishes и/dishes:dishid конечных точек.

342
00:28:41,281 --> 00:28:44,626
Теперь как мы используем Express Router?

343
00:28:44,626 --> 00:28:46,910
Посмотрим, как мы можем использовать его.

344
00:28:46,910 --> 00:28:51,050
Теперь Express Router поставляется вместе с Express, поэтому нам не нужно устанавливать

345
00:28:51,050 --> 00:28:53,130
еще один модуль Node.

346
00:28:53,130 --> 00:28:56,970
Вместо этого мы можем работать с Express, который мы уже установили.

347
00:28:56,970 --> 00:29:02,308
Поэтому для этого в этой подсказке введите const express

348
00:29:02,308 --> 00:29:07,200
= require ('express');.

349
00:29:07,200 --> 00:29:09,950
Поэтому обратите внимание, что, поскольку это мини-приложение,

350
00:29:09,950 --> 00:29:15,000
мы все еще требуем экспресс даже в этом файле dishRouter.js.

351
00:29:15,000 --> 00:29:18,495
И из ваших знаний о модулях Node, как только вы определяете новый файл,

352
00:29:18,495 --> 00:29:20,251
который становится его собственным модулем Node.

353
00:29:20,251 --> 00:29:24,708
И этот модуль Node может быть импортирован в index.js.

354
00:29:24,708 --> 00:29:29,520
Таким образом, вы видите связь уже между тем, как мы можем реструктурировать наше

355
00:29:29,520 --> 00:29:33,415
приложение в несколько файлов с помощью модулей Node.

356
00:29:33,415 --> 00:29:39,525
Таким образом, мы установим требование Express, тогда мы скажем, const

357
00:29:39,525 --> 00:29:44,830
BodyParser требует («body-parser»).

358
00:29:44,830 --> 00:29:50,310
Таким образом, мы уже установили BodyParser на предыдущих этапах упражнения,

359
00:29:50,310 --> 00:29:51,634
поэтому мы можем использовать это.

360
00:29:51,634 --> 00:29:55,040
Теперь, чтобы использовать Express маршрутизатор,

361
00:29:55,040 --> 00:30:00,636
позвольте мне объявить const DishRouter = Express.r.

362
00:30:00,636 --> 00:30:05,769
И на express, он поддерживает этот интерфейс маршрутизатора, так что мы просто

363
00:30:05,769 --> 00:30:11,430
скажем Express.Router и это объявит DishRouter как Express маршрутизатор.

364
00:30:11,430 --> 00:30:13,951
Поэтому во многих приложениях Express

365
00:30:13,951 --> 00:30:18,820
понимание здесь я могу обрабатывать этот код, связанный с DishRouter здесь.

366
00:30:19,830 --> 00:30:26,560
Поэтому, как только я объявляю об этом в Express маршрутизаторе, я могу сказать DishRouter.

367
00:30:28,050 --> 00:30:33,337
И затем на DishRouter он поддерживает метод route method,

368
00:30:33,337 --> 00:30:36,694
который может принимать конечную точку в качестве параметра.

369
00:30:36,694 --> 00:30:41,330
Поэтому я бы просто объявил эту конечную точку a /.

370
00:30:41,330 --> 00:30:44,620
А теперь вам интересно, разве это не посуда?

371
00:30:44,620 --> 00:30:49,630
Вы скоро увидите, что мне нужно смонтировать этот

372
00:30:49,630 --> 00:30:53,140
Express маршрутизатор в моем файле index.js.

373
00:30:53,140 --> 00:31:01,270
Поэтому в моем файле index.js я монтирую этот экспресс-маршрутизатор в конечной точке /dishes.

374
00:31:01,270 --> 00:31:03,300
Монтаж экспресс-маршрутизатора, опять же,

375
00:31:03,300 --> 00:31:05,900
еще одна концепция, которую я хочу, чтобы вы поняли.

376
00:31:05,900 --> 00:31:08,408
Опять же, я проиллюстрирую это вам через короткое время.

377
00:31:08,408 --> 00:31:13,368
Теперь DishRouter.Route означает, что, используя этот подход,

378
00:31:13,368 --> 00:31:17,526
мы объявляем конечную точку в одном месте. Таким

379
00:31:17,526 --> 00:31:21,316
образом, вы можете цепочки все получить, PUT, POST,

380
00:31:21,316 --> 00:31:25,219
удалить методы уже делают этот маршрутизатор блюдо.

381
00:31:25,219 --> 00:31:30,139
Теперь, когда вы смотрите на index.js, посмотрите, как мы это имплицировали.

382
00:31:30,139 --> 00:31:36,029
Таким образом, у нас есть app.all, а затем /dishes, app.get/dishes и/dishes.

383
00:31:36,029 --> 00:31:40,795
Теперь, если вы допустили ошибку, и их инструкция app.post

384
00:31:40,795 --> 00:31:45,580
/dishes вместо этого, если вы просто введете /dish, то что происходит?

385
00:31:45,580 --> 00:31:49,050
Операция POST не будет поддерживаться на блюдах, но

386
00:31:49,050 --> 00:31:51,730
будет поддерживаться на конечной точке /dish.

387
00:31:53,170 --> 00:31:59,220
Чтобы избежать этой проблемы, экспресс-маршрутизатор поддерживает эту конечную точку маршрута.

388
00:31:59,220 --> 00:32:00,090
В конечной точке маршрута

389
00:32:00,090 --> 00:32:05,860
просто укажите конечную точку, в которой будет работать этот маршрутизатор.

390
00:32:05,860 --> 00:32:10,890
И затем, метод удаления части get put, это просто приковано к этому.

391
00:32:10,890 --> 00:32:16,300
Таким образом, это будет одна группа реализаций методов все вместе.

392
00:32:16,300 --> 00:32:20,345
Поэтому они используют экспресс-маршрутизатор.

393
00:32:20,345 --> 00:32:24,185
Таким образом, он поставляется с парой очень полезной

394
00:32:24,185 --> 00:32:28,525
поддержки, чтобы убедиться, что ваша реализация верна.

395
00:32:28,525 --> 00:32:32,190
Так что теперь, когда мы собираемся сделать это как маршрутизатор посуды,

396
00:32:32,190 --> 00:32:37,920
то, что я собираюсь сделать, я собираюсь удалить эту вещь отсюда.

397
00:32:37,920 --> 00:32:42,990
Теперь, что блюда IDN точка, я собираюсь оставить это

398
00:32:42,990 --> 00:32:47,565
вам в качестве упражнения в вашем первом задании

399
00:32:47,565 --> 00:32:54,180
, но конечная точка блюда, я собираюсь вырезать это, вплоть до всех.

400
00:32:54,180 --> 00:32:59,350
Я собираюсь вырезать это из index.js5 и

401
00:32:59,350 --> 00:33:04,580
переместить это в DishRouter здесь.

402
00:33:04,580 --> 00:33:11,887
Теперь, когда я перемещаю это в DishRouter, мне больше не нужно это app.all.

403
00:33:11,887 --> 00:33:18,267
Я просто цепь это в маршрут, поэтому я просто скажу .all, а

404
00:33:18,267 --> 00:33:24,210
затем мне больше не нужно это определение конечной точки там.

405
00:33:24,210 --> 00:33:24,900
Вот оно. Так что

406
00:33:24,900 --> 00:33:28,390
будет сказано «все», а потом мы скажем «req», «res», «следующий».

407
00:33:28,390 --> 00:33:31,470
И это, все работает на этой конкретной конечной точке,

408
00:33:31,470 --> 00:33:33,690
уже указанной здесь.

409
00:33:33,690 --> 00:33:37,920
Теперь, не только это, мы можем цепочку оставшихся методов.

410
00:33:37,920 --> 00:33:41,360
Вот почему вы видите, что я удалил точку с запятой отсюда.

411
00:33:41,360 --> 00:33:46,270
Я собираюсь удалить это приложение, а затем прикрепить его к этому.

412
00:33:46,270 --> 00:33:51,600
Таким образом, получает также изменяется в маршруте, а затем я могу удалить

413
00:33:53,140 --> 00:33:57,740
эту часть, обработка останется точно такой же, как и раньше.

414
00:33:57,740 --> 00:34:05,520
Таким образом, я удалю приложение там.

415
00:34:05,520 --> 00:34:10,850
И снова удалите это из поста.

416
00:34:10,850 --> 00:34:11,865
И то же самое.

417
00:34:17,447 --> 00:34:22,248
Для пута, и

418
00:34:22,248 --> 00:34:27,360
для удаления, то же самое.

419
00:34:27,360 --> 00:34:30,800
Обратите внимание, что здесь, здесь или

420
00:34:30,800 --> 00:34:34,670
здесь нет точек с запятой, но последний, удаление, будет иметь точку с запятой.

421
00:34:34,670 --> 00:34:40,810
Таким образом, эта группа представляет собой одну единицу, реализованную с помощью

422
00:34:40,810 --> 00:34:45,930
dish маршрутизатора на этом конкретном маршрутизаторе, и все они соединены друг с другом.

423
00:34:47,640 --> 00:34:52,610
И также, конечно, с удалением, мне нужно удалить эту конечную точку.

424
00:34:52,610 --> 00:34:56,626
Вот, видишь ли, чистая структура кода здесь.

425
00:34:56,626 --> 00:35:02,100
Таким образом, по существу, заканчивается реализацией DishRouter, правильно,

426
00:35:02,100 --> 00:35:07,700
помните, что этот DishRouter определен внутри файла dishRouter.js.

427
00:35:07,700 --> 00:35:12,870
Теперь мне нужно экспортировать это из этого модуля узла.

428
00:35:12,870 --> 00:35:17,500
Поэтому, чтобы экспортировать это, я перейду вниз здесь, и

429
00:35:17,500 --> 00:35:22,877
я скажу module.exports и

430
00:35:22,877 --> 00:35:26,170
скажу, DishRouter.

431
00:35:26,170 --> 00:35:27,030
Вот оно.

432
00:35:27,030 --> 00:35:34,920
Итак, теперь мой DishRouter экспортирует все, что мне нужно.

433
00:35:34,920 --> 00:35:41,170
Теперь ты смотришь на это и говоришь, что насчет блюда Колон.

434
00:35:41,170 --> 00:35:44,302
Это будет частью вашего первого задания.

435
00:35:44,302 --> 00:35:47,010
Мало того, что вы будете внедрять для

436
00:35:47,010 --> 00:35:53,000
двух дополнительных конечных точек REST API, рекламных акций и лидеров.

437
00:35:53,000 --> 00:35:57,960
Но это уже показывает вам структуру того,

438
00:35:57,960 --> 00:36:03,080
как выглядит реализация экспресс-маршрутизаторов поддержки res API.

439
00:36:03,080 --> 00:36:05,070
Так что это для DishRouter.Route.

440
00:36:05,070 --> 00:36:09,848
И последнее, прежде чем я забуду,

441
00:36:09,848 --> 00:36:18,140
мы должны сказать Dishrouter.use (Bodyparser.json ()).

442
00:36:20,326 --> 00:36:23,852
Теперь, как только вы завершите реализацию DishRouter,

443
00:36:23,852 --> 00:36:26,130
мы можем перейти к файлу index.js.

444
00:36:26,130 --> 00:36:34,020
Так как этот DishRouter является еще одним узловым модулем, тем не менее тонким узлом

445
00:36:34,020 --> 00:36:38,120
Поэтому нам нужно импортировать это в наше приложение.

446
00:36:38,120 --> 00:36:44,250
Так что прямо здесь, я собираюсь импортировать const

447
00:36:46,000 --> 00:36:52,100
DishRouter равен требованию.

448
00:36:52,100 --> 00:36:56,626
Теперь, поскольку это файловый модуль узла,

449
00:36:56,626 --> 00:37:03,000
я скажу. /Маршруты/Посудомоечная машина.

450
00:37:03,000 --> 00:37:09,850
И как только я объявил их там, тогда я вхожу в код здесь.

451
00:37:09,850 --> 00:37:14,230
И прямо там, я говорю app.use.

452
00:37:14,230 --> 00:37:19,130
И я монтирую маршрутизатор в конечной точке.

453
00:37:19,130 --> 00:37:20,930
Итак, как мне смонтировать маршрутизатор?

454
00:37:20,930 --> 00:37:25,790
Первый параметр здесь, я буду указывать слэш блюда.

455
00:37:25,790 --> 00:37:29,480
И второй параметр, укажите DishRouter.

456
00:37:30,810 --> 00:37:31,830
И вот оно.

457
00:37:31,830 --> 00:37:35,080
Так что это означает, что в моем экспресс-приложении

458
00:37:36,205 --> 00:37:41,435
любой запрос, приходящий к этой конечной точке косой черты, будет обрабатываться DishRouter,

459
00:37:41,435 --> 00:37:45,615
и это будет сделано с помощью кода, который присутствует здесь,

460
00:37:45,615 --> 00:37:50,755
потому что мы сказали маршрут DishRouter, и поэтому обратите внимание, что это говорит косая черта,

461
00:37:50,755 --> 00:37:54,575
так что это означает, что монтируется в конечной точке слэша.

462
00:37:54,575 --> 00:37:59,378
Вот почему все, что приходит через косую посуду, будет отправлено на это и

463
00:37:59,378 --> 00:38:00,890
будет обрабатываться этим.

464
00:38:02,730 --> 00:38:07,000
Большой намек для вас, чтобы подумать о том, как вы бы реализовали

465
00:38:07,000 --> 00:38:11,020
конечную точку идентификатора блюда толстой кишки.

466
00:38:11,020 --> 00:38:16,440
Вы по-прежнему будете использовать тот же файл dishRouter.js, чтобы также реализовать поддержку

467
00:38:16,440 --> 00:38:21,670
этого, /dishes/:dishid конечной точки.

468
00:38:21,670 --> 00:38:24,580
Это еще один большой намек для тебя, хорошо.

469
00:38:24,580 --> 00:38:29,260
С этими изменениями, давайте сохраним изменения, которые мы сделали

470
00:38:29,260 --> 00:38:33,870
в нашем приложении, а затем перезапустите наш сервер, а

471
00:38:33,870 --> 00:38:37,480
затем посмотрим, как наш сервер будет делать свою работу.

472
00:38:38,850 --> 00:38:44,190
Перейдя к терминалу, позвольте мне перезапустить этот сервер, введя npm start.

473
00:38:44,190 --> 00:38:47,340
И как только сервер будет запущен, я пойду к почтальонам и

474
00:38:47,340 --> 00:38:50,220
отправлю запросы от почтальона на этот сервер.

475
00:38:51,220 --> 00:38:57,110
Отправляясь в почтальон, теперь я знаю, что мой сервер поддерживает только

476
00:38:57,110 --> 00:39:01,690
конечную точку блюда, я реализовал часть блюда ID его.

477
00:39:01,690 --> 00:39:05,570
Поэтому позвольте мне отправить запрос на местные блюда хоста, и

478
00:39:05,570 --> 00:39:08,590
вы увидите, что он работает точно так же, как и раньше.

479
00:39:08,590 --> 00:39:12,910
Теперь, если вы сделали предыдущий запрос в сообщении, вы можете просто нажать на это, а

480
00:39:12,910 --> 00:39:15,150
затем повторно отправить этот запрос.

481
00:39:16,940 --> 00:39:26,680
Операция Put не работает, после операции, Работает, как вы видите там.

482
00:39:26,680 --> 00:39:32,370
И тогда давайте вызовем операцию удаления на тарелке.

483
00:39:32,370 --> 00:39:36,210
И он говорит, что удаление всех блюд, как ожидалось.

484
00:39:36,210 --> 00:39:45,230
Таким образом, это реализация поддержки остальных API с использованием экспресс-маршрутизатора.

485
00:39:45,230 --> 00:39:48,950
Этим мы завершаем вторую половину этого упражнения.

486
00:39:48,950 --> 00:39:54,490
Это подходящее время для вас сделать комментарий с помощью экспресс-маршрутизатора сообщений.

487
00:39:55,830 --> 00:40:00,896
Теперь, когда мы завершили это упражнение, где мы увидели, как Express может

488
00:40:00,896 --> 00:40:06,450
быть использован для поддержки реализации поддержки конечных точек Res API на нашем сервере,

489
00:40:06,450 --> 00:40:08,900
а также использования Express маршрутизатора,

490
00:40:08,900 --> 00:40:13,906
пришло время перейти к первому заданию, которое следует за этим уроком.

491
00:40:13,906 --> 00:40:20,030
[ МУЗЫКА]