1
00:00:00,000 --> 00:00:05,340
Теперь, когда мы

2
00:00:05,340 --> 00:00:11,610
завершили реализацию сервера REST API с помощью Express и MongoDB в этом курсе,

3
00:00:11,610 --> 00:00:14,990
следующая немедленная мысль, которая может возникнуть в вашем уме,

4
00:00:14,990 --> 00:00:18,555
так как мы уже разработали клиентские

5
00:00:18,555 --> 00:00:21,460
приложения, будь то угловое приложение, ионное приложение

6
00:00:21,460 --> 00:00:25,380
или Приложение Native Script в предыдущих курсах,

7
00:00:25,380 --> 00:00:29,820
как мы интегрируем их вместе, чтобы наше клиентское приложение могло

8
00:00:29,820 --> 00:00:35,780
взаимодействовать с полнофункциональным REST API сервером, который мы разработали в этом курсе?

9
00:00:35,780 --> 00:00:39,605
Итак, это то, что мы рассмотрим на этом уроке,

10
00:00:39,605 --> 00:00:44,715
в этой лекции, и в двух упражнениях, которые следуют за этой лекцией.

11
00:00:44,715 --> 00:00:46,655
Таким образом, в конце этого урока

12
00:00:46,655 --> 00:00:49,295
у вас будет угловой клиент, который мы

13
00:00:49,295 --> 00:00:52,220
сможем общаться с сервером, который вы только что разработали в

14
00:00:52,220 --> 00:00:55,265
этом курсе, и иметь возможность поддерживать

15
00:00:55,265 --> 00:01:01,410
полноценное представление на стороне клиента всего нашего приложения.

16
00:01:01,410 --> 00:01:03,860
Таким образом, мы увидим, что мы разработали

17
00:01:03,860 --> 00:01:11,150
полное приложение от конца до конца от клиента до стороны сервера.

18
00:01:11,150 --> 00:01:13,895
Аналогичный подход также может быть использован с

19
00:01:13,895 --> 00:01:17,290
вашим Ionic клиентом или с вашим клиентом Native скриптов,

20
00:01:17,290 --> 00:01:20,430
учитывая тот факт, что как Ionic, так и Native скрипты были

21
00:01:20,430 --> 00:01:24,420
разработаны с помощью движка Angular за кулисами.

22
00:01:24,420 --> 00:01:31,100
Таким образом, выполнение аналогичного набора шагов должно быть в состоянии сделать ваш Ionic клиент, а также

23
00:01:31,100 --> 00:01:35,240
ваш Native скрипт клиент общаться с

24
00:01:35,240 --> 00:01:40,295
сервером API Express plus MongoDB, который мы разработали в этом курсе.

25
00:01:40,295 --> 00:01:43,415
Для интеграции клиента и сервера,

26
00:01:43,415 --> 00:01:44,810
как мы уже поняли,

27
00:01:44,810 --> 00:01:50,020
наш сервер уже реализован для поддержки полноценного REST API.

28
00:01:50,020 --> 00:01:51,695
С нашей клиентской стороны,

29
00:01:51,695 --> 00:01:53,240
будь то угловой клиент,

30
00:01:53,240 --> 00:01:55,750
ионный клиент или собственный клиент сценария,

31
00:01:55,750 --> 00:02:00,740
все они взаимодействуют с сервером, используя конечные точки REST API.

32
00:02:00,740 --> 00:02:06,135
Таким образом, когда клиент отправляет запрос на сервер в конечной точке REST API,

33
00:02:06,135 --> 00:02:10,729
сервер будет отвечать с соответствующими данными JSON обратно клиенту,

34
00:02:10,729 --> 00:02:16,720
и клиент может затем использовать данные JSON для отображения представлений для пользователя.

35
00:02:16,720 --> 00:02:22,970
Таким образом, учитывая такое понимание связи между клиентом и сервером,

36
00:02:22,970 --> 00:02:25,780
интеграция должна быть достаточно простой.

37
00:02:25,780 --> 00:02:26,960
Но теперь, конечно,

38
00:02:26,960 --> 00:02:30,820
когда мы разработали наш Angular или Ionic или клиент NativeScript,

39
00:02:30,820 --> 00:02:34,990
мы не делали полноценную часть аутентификации пользователя,

40
00:02:34,990 --> 00:02:38,225
потому что у нас не было этого на нашем сервере JSON.

41
00:02:38,225 --> 00:02:43,250
Теперь, когда у нас есть аутентификация пользователя, встроенная в нашу серверную сторону,

42
00:02:43,250 --> 00:02:47,810
нам нужно модифицировать наши клиентские приложения,

43
00:02:47,810 --> 00:02:52,970
чтобы они могли выполнять аутентификацию пользователя на стороне сервера,

44
00:02:52,970 --> 00:02:56,660
путем публикации информации для входа на сервер, а затем

45
00:02:56,660 --> 00:03:01,190
получения токена аутентификации со стороны сервера,

46
00:03:01,190 --> 00:03:04,400
и затем, общаясь с сервером, включая

47
00:03:04,400 --> 00:03:08,175
токен аутентификации в заголовке сообщений запроса.

48
00:03:08,175 --> 00:03:10,130
Итак, все это означает, что нам нужно делать

49
00:03:10,130 --> 00:03:12,860
небольшие корректировки как для клиента, так и для сервера,

50
00:03:12,860 --> 00:03:15,860
чтобы они могли общаться друг с другом.

51
00:03:15,860 --> 00:03:21,020
Один аспект, с которым я не сталкивался в упражнении ранее,

52
00:03:21,020 --> 00:03:26,445
заключается в том, как сервер будет обрабатывать параметры запроса, которые приходят со стороны клиента.

53
00:03:26,445 --> 00:03:27,970
Таким образом, как мы поняли,

54
00:03:27,970 --> 00:03:31,925
когда клиентская сторона отправляет запрос на

55
00:03:31,925 --> 00:03:37,360
избранное блюдо или избранного лидера или продвижение функции,

56
00:03:37,360 --> 00:03:41,665
мы увидели, что URL включает блюда,

57
00:03:41,665 --> 00:03:45,095
функция вопросительного знака равна true в

58
00:03:45,095 --> 00:03:48,840
URL-адресе запроса, который приходит со стороны клиента.

59
00:03:48,840 --> 00:03:51,670
Теперь, в данных на стороне сервера,

60
00:03:51,670 --> 00:03:54,040
мы уже видели, что блюдо,

61
00:03:54,040 --> 00:03:56,090
продвижение или лидер,

62
00:03:56,090 --> 00:03:59,835
включает флаг функции уже в данных JSON.

63
00:03:59,835 --> 00:04:02,975
Таким образом, когда этот запрос приходит на сторону сервера,

64
00:04:02,975 --> 00:04:10,285
то сервер должен иметь возможность извлечь этот параметр запроса из входящего запроса,

65
00:04:10,285 --> 00:04:16,865
а затем соответствующим образом выполнить запрос

66
00:04:16,865 --> 00:04:24,485
MongoDB, а затем получить только результаты, где этот флаг установлен в true.

67
00:04:24,485 --> 00:04:26,365
Итак, чтобы сделать это, как мы видели,

68
00:04:26,365 --> 00:04:36,380
URL-адрес, который используется для отправки запроса на сервер, является /dishes? feature=true.

69
00:04:36,380 --> 00:04:42,365
Таким образом, мы будем поставлять параметры запроса на нашу сторону сервера.

70
00:04:42,365 --> 00:04:47,510
Теперь, кроме того, когда эта информация получена на стороне сервера,

71
00:04:47,510 --> 00:04:51,890
теперь, мы видели, что раньше, когда мы делали запрос на получение на стороне сервера,

72
00:04:51,890 --> 00:04:56,975
мы просто сказали, что блюда найти, а затем мы находим все блюда, а затем возвращаем их,

73
00:04:56,975 --> 00:05:03,675
когда запрос get отправляется в DishRouterRoute/.

74
00:05:03,675 --> 00:05:09,470
Такая же логика применима как к промо-роутеру, так и к роутеру лидера.

75
00:05:09,470 --> 00:05:14,805
Теперь, когда вы включаете такой параметр запроса в URL-адрес,

76
00:05:14,805 --> 00:05:19,270
как наша серверная сторона сможет извлечь этот параметр запроса?

77
00:05:19,270 --> 00:05:22,730
Таким образом, это где, когда входящий запрос имеет

78
00:05:22,730 --> 00:05:27,055
этот параметр запроса, прикрепленный к входящему URL-адресу,

79
00:05:27,055 --> 00:05:31,835
экспресс-сервер автоматически обработает его и превратит его в

80
00:05:31,835 --> 00:05:38,910
объект JSON, который загружается в сообщение запроса, поступающее на стороне сервера.

81
00:05:38,910 --> 00:05:45,185
Теперь это доступно на стороне сервера в виде req.query.

82
00:05:45,185 --> 00:05:49,665
Таким образом, любые параметры запроса, которые вы

83
00:05:49,665 --> 00:05:56,860
включили в URL-адрес, будут преобразованы в соответствующие объекты JSON с набором информации, как показано здесь,

84
00:05:56,860 --> 00:06:01,350
а затем загружены в объект запроса на стороне сервера.

85
00:06:01,350 --> 00:06:04,670
Таким образом, используя req.query на стороне сервера,

86
00:06:04,670 --> 00:06:08,105
мы сможем получить эти параметры запроса.

87
00:06:08,105 --> 00:06:11,840
Итак, когда вы выполняете запрос get на стороне сервера,

88
00:06:11,840 --> 00:06:18,635
вы говорите dishes.find, а затем включаете req.query в поиск.

89
00:06:18,635 --> 00:06:25,040
Таким образом, когда MongoDB запрашивается, то

90
00:06:25,040 --> 00:06:31,160
только те записи или только те документы, для которых признакам установлено значение true, будут

91
00:06:31,160 --> 00:06:38,270
извлечены из MongoDB и переданы обратно в этот метод get здесь,

92
00:06:38,270 --> 00:06:41,625
а затем, могут быть возвращены на стороне клиента.

93
00:06:41,625 --> 00:06:49,745
Таким образом, это так же просто, как и в обработке параметров запроса на нашей стороне сервера.

94
00:06:49,745 --> 00:06:55,135
Итак, это обновление мы сделаем как с маршрутизатором тарелки,

95
00:06:55,135 --> 00:07:01,225
промо-роутером, так и с ведущим маршрутизатором на нашей стороне сервера.

96
00:07:01,225 --> 00:07:04,880
Следующая часть, конечно же, аутентификация пользователя.

97
00:07:04,880 --> 00:07:07,530
Таким образом, как мы поняли на стороне сервера, у

98
00:07:07,530 --> 00:07:11,095
нас уже есть эти конечные точки REST API,

99
00:07:11,095 --> 00:07:13,780
которые полезны для аутентификации пользователей.

100
00:07:13,780 --> 00:07:18,855
В частности, когда вы делаете сообщение в/users/login,

101
00:07:18,855 --> 00:07:22,040
с именем пользователя и паролем,

102
00:07:22,040 --> 00:07:26,140
вы сможете аутентифицировать пользователя на стороне сервера.

103
00:07:26,140 --> 00:07:30,535
Теперь, когда пользователь успешно аутентифицирован на стороне сервера,

104
00:07:30,535 --> 00:07:35,059
то ответное сообщение, поступающее со стороны сервера, будет включать

105
00:07:35,059 --> 00:07:43,345
веб-маркер JSON в тело ответа входящего ответного сообщения со стороны сервера.

106
00:07:43,345 --> 00:07:44,810
Итак, на стороне клиента,

107
00:07:44,810 --> 00:07:49,210
мы должны иметь возможность извлечь этот токен, а затем использовать этот токен впоследствии.

108
00:07:49,210 --> 00:07:52,700
Таким образом, когда клиент получает ответное сообщение со

109
00:07:52,700 --> 00:07:57,140
стороны сервера, и пользователь успешно аутентифицирован на стороне сервера,

110
00:07:57,140 --> 00:07:59,690
ответное сообщение будет содержать веб-токен JSON,

111
00:07:59,690 --> 00:08:02,290
который должен быть извлечен, и после этого

112
00:08:02,290 --> 00:08:05,240
клиент должен включить этот веб-токен JSON

113
00:08:05,240 --> 00:08:10,620
в для каждого исходящего запроса со стороны клиента.

114
00:08:10,620 --> 00:08:13,585
Итак, как мы справимся со всем этим набором операций?

115
00:08:13,585 --> 00:08:15,800
Теперь, это где мы будем реализовывать

116
00:08:15,800 --> 00:08:20,255
другую службу, которая будет использоваться на нашей стороне клиента,

117
00:08:20,255 --> 00:08:21,720
в нашем угловом клиенте,

118
00:08:21,720 --> 00:08:23,810
называемом службой аутентификации,

119
00:08:23,810 --> 00:08:30,185
и именно там мы будем обрабатывать все операции входа и выхода из системы.

120
00:08:30,185 --> 00:08:33,850
Теперь процесс выхода из системы довольно прост, но

121
00:08:33,850 --> 00:08:37,840
если мы уничтожим веб-токен JSON, который у нас есть на стороне клиента,

122
00:08:37,840 --> 00:08:41,160
то клиент больше не сможет получить доступ к серверу.

123
00:08:41,160 --> 00:08:43,850
Таким образом, это так же просто, как просто уничтожить

124
00:08:43,850 --> 00:08:48,095
веб-токен JSON на стороне клиента для выхода из этого клиента.

125
00:08:48,095 --> 00:08:50,460
Итак, учитывая это понимание,

126
00:08:50,460 --> 00:08:54,110
давайте посмотрим шаги, которые участвуют

127
00:08:54,110 --> 00:08:59,760
в выполнении аутентификации пользователя и обработки аутентификации пользователя на стороне клиента.

128
00:08:59,760 --> 00:09:03,320
Таким образом, чтобы обработать аутентификацию пользователя на стороне клиента,

129
00:09:03,320 --> 00:09:08,945
клиент отправит почтовый запрос в конечную точку /users/login,

130
00:09:08,945 --> 00:09:14,110
а тело почтового запроса будет содержать имя пользователя и пароль.

131
00:09:14,110 --> 00:09:16,660
Мы используем аутентификацию для входа в систему в этом случае.

132
00:09:16,660 --> 00:09:18,650
Теперь, для аутентификации Facebook снова,

133
00:09:18,650 --> 00:09:22,355
это другая настройка, которую я не собираюсь обсуждать прямо сейчас.

134
00:09:22,355 --> 00:09:26,465
Но тело запроса, как вы увидите для локальной аутентификации,

135
00:09:26,465 --> 00:09:28,730
будет содержать имя пользователя и пароль.

136
00:09:28,730 --> 00:09:33,170
Таким образом, когда пользователь успешно аутентифицирован на стороне сервера,

137
00:09:33,170 --> 00:09:36,410
сервер ответит обратно

138
00:09:36,410 --> 00:09:41,425
клиенту, включив веб-маркер JSON в ответное сообщение.

139
00:09:41,425 --> 00:09:46,070
Таким образом, когда клиент получает ответное сообщение со стороны сервера,

140
00:09:46,070 --> 00:09:49,790
клиенту придется захватить этот веб-токен JSON,

141
00:09:49,790 --> 00:09:55,025
а затем сохранить веб-токен JSON в локальном хранилище на стороне клиента.

142
00:09:55,025 --> 00:10:01,250
После этого клиент должен включать этот токен в каждый исходящий запрос.

143
00:10:01,250 --> 00:10:04,455
Итак, как это делается на стороне клиента?

144
00:10:04,455 --> 00:10:06,155
Прежде всего, конечно,

145
00:10:06,155 --> 00:10:11,980
вам нужно сохранить входящий веб-токен JSON в локальное хранилище,

146
00:10:11,980 --> 00:10:16,790
и это делается в сервисе аутентификации, который мы будем реализовывать на стороне клиента.

147
00:10:16,790 --> 00:10:19,975
Теперь, для каждого исходящего запроса,

148
00:10:19,975 --> 00:10:22,850
клиент будет включать этот токен в заголовок,

149
00:10:22,850 --> 00:10:27,100
заголовок авторизации исходящего запроса.

150
00:10:27,100 --> 00:10:28,555
Итак, как это делается?

151
00:10:28,555 --> 00:10:33,935
Итак, вот где мы собираемся взять помощь перехватчика HTTP,

152
00:10:33,935 --> 00:10:37,265
который поддерживает HttpClient в Angular.

153
00:10:37,265 --> 00:10:39,675
Таким образом, с помощью перехватчика HTTP,

154
00:10:39,675 --> 00:10:42,305
перехватчик позволяет нам перехватывать

155
00:10:42,305 --> 00:10:45,875
каждое исходящее сообщение запроса или даже

156
00:10:45,875 --> 00:10:50,010
перехватывать каждое входящее ответное сообщение, если вы так хотите.

157
00:10:50,010 --> 00:10:52,175
Но в приложении Angular

158
00:10:52,175 --> 00:10:56,215
мы собираемся реализовать перехватчик запросов,

159
00:10:56,215 --> 00:10:59,540
который я проиллюстрирую в упражнении позже.

160
00:10:59,540 --> 00:11:02,460
В перехватчике запросов HTTP,

161
00:11:02,460 --> 00:11:04,375
когда сообщение запроса перехвачено,

162
00:11:04,375 --> 00:11:09,915
каждое исходящее сообщение запроса будет перехвачено, а затем веб-токен JSON

163
00:11:09,915 --> 00:11:15,650
будет вставлен в заголовок авторизации сообщения запроса.

164
00:11:15,650 --> 00:11:20,290
Затем после этого сообщение запроса будет передано на сторону сервера.

165
00:11:20,290 --> 00:11:26,825
Таким образом, каждый исходящий запрос после аутентификации пользователя на стороне сервера,

166
00:11:26,825 --> 00:11:30,620
каждый исходящий запрос со стороны клиента будет нести

167
00:11:30,620 --> 00:11:35,590
веб-токен JSON в заголовке авторизации исходящего запроса.

168
00:11:35,590 --> 00:11:38,600
Теперь, как только клиент выйдет из системы,

169
00:11:38,600 --> 00:11:42,595
веб-токен JSON будет уничтожен на стороне клиента.

170
00:11:42,595 --> 00:11:47,215
Таким образом, после этого исходящие запросы больше не будут содержать веб-токен

171
00:11:47,215 --> 00:11:50,160
JSON, потому что веб-токен JSON не существует на стороне клиента.

172
00:11:50,160 --> 00:11:53,240
Таким образом, пользователь теряет аутентификацию.

173
00:11:53,240 --> 00:12:00,030
Таким образом, мы будем обрабатывать процесс входа и выхода из системы на стороне клиента,

174
00:12:00,030 --> 00:12:02,290
общаясь с сервером,

175
00:12:02,290 --> 00:12:04,225
а затем получать веб-токен JSON,

176
00:12:04,225 --> 00:12:08,845
а затем включать веб-токен JSON в каждый исходящий запрос.

177
00:12:08,845 --> 00:12:14,250
Теперь, с таким пониманием того, как клиент и сервер будут взаимодействовать,

178
00:12:14,250 --> 00:12:18,205
давайте перейдем к следующим двум упражнениям.

179
00:12:18,205 --> 00:12:22,540
Во-первых, мы обновим серверную сторону с несколькими добавлениями,

180
00:12:22,540 --> 00:12:28,220
чтобы она могла хорошо интегрироваться с нашим сайтом клиента.

181
00:12:28,220 --> 00:12:32,750
После этого мы обновим клиентскую сторону или, скорее, я дам вам

182
00:12:32,750 --> 00:12:36,215
полноценное клиентское приложение, которое я

183
00:12:36,215 --> 00:12:40,795
взял из предыдущего углового курса, а затем я обновлю его, что

184
00:12:40,795 --> 00:12:45,875
также дает нам возможность использовать HTTP-перехватчики

185
00:12:45,875 --> 00:12:51,595
как на исходящих запросах, так и на входящие ответные сообщения.

186
00:12:51,595 --> 00:12:56,090
Итак, мы разберемся с ними в следующих двух упражнениях,

187
00:12:56,090 --> 00:12:58,370
а в конце вы

188
00:12:58,370 --> 00:13:02,530
поймете, как интегрировать клиента и серверную сторону.