1
00:00:03,650 --> 00:00:06,795
Теперь, когда мы завершили реализацию

2
00:00:06,795 --> 00:00:11,395
REST API сервера с использованием Express и MongoDB в этом курсе,

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

4
00:00:14,990 --> 00:00:20,490
так как мы уже разработали клиентские приложения на предыдущих курсах,

5
00:00:20,490 --> 00:00:24,930
как мы интегрируем их вместе, чтобы наши может

6
00:00:24,930 --> 00:00:30,880
взаимодействовать с полноценным REST API сервером, который мы разработали в этом курсе?

7
00:00:30,880 --> 00:00:33,820
Итак, это то, что мы рассмотрим в

8
00:00:33,820 --> 00:00:39,820
этой лекции и двух упражнений, которые следуют за этой лекцией.

9
00:00:39,820 --> 00:00:41,770
Итак, в конце этого урока

10
00:00:41,770 --> 00:00:44,390
у вас будет React Client, который будет

11
00:00:44,390 --> 00:00:47,330
иметь возможность общаться с сервером, который вы только что разработали в

12
00:00:47,330 --> 00:00:50,345
этом курсе, и иметь возможность поддерживать

13
00:00:50,345 --> 00:00:56,510
полноценное представление на стороне клиента всего нашего приложения.

14
00:00:56,510 --> 00:00:58,970
Таким образом, мы увидим, что мы разработали

15
00:00:58,970 --> 00:01:02,565
полное

16
00:01:02,565 --> 00:01:07,795
приложение от конца до конца от клиента до стороны сервера в этом курсе.

17
00:01:07,795 --> 00:01:10,910
Для интеграции клиента и сервера,

18
00:01:10,910 --> 00:01:13,670
как мы поняли, наш сервер уже

19
00:01:13,670 --> 00:01:17,525
реализован для поддержки полноценного REST API.

20
00:01:17,525 --> 00:01:19,220
С нашей клиентской стороны,

21
00:01:19,220 --> 00:01:20,720
будь то угловой клиент,

22
00:01:20,720 --> 00:01:23,340
ионный клиент или собственный клиент сценария,

23
00:01:23,340 --> 00:01:28,240
все они взаимодействуют с сервером, используя конечные точки REST API.

24
00:01:28,240 --> 00:01:33,630
Таким образом, когда клиент отправляет запрос на сервер в конечной точке REST API,

25
00:01:33,630 --> 00:01:38,190
сервер будет отвечать с соответствующими данными JSON обратно клиенту.

26
00:01:38,190 --> 00:01:44,225
Затем клиент может использовать данные JSON для визуализации представлений для пользователя.

27
00:01:44,225 --> 00:01:50,450
Таким образом, учитывая такое понимание связи между клиентом и сервером,

28
00:01:50,450 --> 00:01:53,745
интеграция должна быть достаточно простой.

29
00:01:53,745 --> 00:01:58,475
Теперь, когда у нас есть аутентификация пользователя, встроенная в нашу серверную сторону,

30
00:01:58,475 --> 00:02:03,330
нам нужно модифицировать наши клиентские приложения,

31
00:02:03,330 --> 00:02:08,400
чтобы они могли выполнять пользовательскую аутентификацию

32
00:02:08,400 --> 00:02:12,200
на стороне сервера, разместив регистрационную информацию на сервере, а затем

33
00:02:12,200 --> 00:02:16,010
получив токен аутентификации со

34
00:02:16,010 --> 00:02:19,120
стороны сервера и затем взаимодействовать с сервером,

35
00:02:19,120 --> 00:02:23,700
включая токен аутентификации в заголовке сообщений запроса.

36
00:02:23,700 --> 00:02:27,050
Таким образом, все это означает, что нам нужно сделать небольшие корректировки как для

37
00:02:27,050 --> 00:02:31,345
клиента, так и для сервера, чтобы они могли общаться друг с другом.

38
00:02:31,345 --> 00:02:36,530
Один аспект, с которым я не сталкивался в упражнении ранее,

39
00:02:36,530 --> 00:02:41,970
заключается в том, как сервер будет обрабатывать параметры запроса, которые приходят со стороны клиента.

40
00:02:41,970 --> 00:02:43,480
Таким образом, как мы поняли,

41
00:02:43,480 --> 00:02:47,450
когда клиентская сторона отправляет запрос на

42
00:02:47,450 --> 00:02:53,035
избранное блюдо или избранного лидера или популярного продвижения,

43
00:02:53,035 --> 00:02:55,910
мы увидели, что URL включает в себя,

44
00:02:55,910 --> 00:02:59,590
функция знака вопроса блюда равна

45
00:02:59,590 --> 00:03:04,370
true в URL-адресе запроса, который приходит со стороны клиента.

46
00:03:04,370 --> 00:03:07,210
Теперь, в данных на стороне сервера,

47
00:03:07,210 --> 00:03:09,585
мы уже видели, что блюдо,

48
00:03:09,585 --> 00:03:15,370
продвижение или лидер включает флаг уже в данных JSON.

49
00:03:15,370 --> 00:03:18,649
Таким образом, когда этот запрос приходит на сторону сервера,

50
00:03:18,649 --> 00:03:21,394
то сервер должен иметь возможность извлечь

51
00:03:21,394 --> 00:03:26,765
этот параметр запроса из входящего запроса, а затем

52
00:03:26,765 --> 00:03:32,390
соответствующим образом выполнить запрос

53
00:03:32,390 --> 00:03:39,950
MongoDB, а затем получить только результаты, где этот флаг установлен в true.

54
00:03:39,950 --> 00:03:41,740
Таким образом, чтобы сделать это, как мы видели,

55
00:03:41,740 --> 00:03:47,075
URL, который используется для отправки запроса на сервер, является,

56
00:03:47,075 --> 00:03:52,030
косой черты блюда вопросительный знак признакам равен true.

57
00:03:52,030 --> 00:03:57,905
Таким образом, мы будем поставлять параметры запроса на нашу сторону сервера.

58
00:03:57,905 --> 00:04:02,610
Теперь, кроме того, когда эта информация получена на стороне сервера,

59
00:04:02,610 --> 00:04:07,430
теперь мы видели, что раньше, когда мы сделали запрос на получение на стороне сервера,

60
00:04:07,430 --> 00:04:10,190
мы просто сказали блюда найти, а затем мы найдем

61
00:04:10,190 --> 00:04:13,135
все блюда, а затем вернем их, когда

62
00:04:13,135 --> 00:04:19,745
запрос получить отправляется на блюдо маршрутизатора косой черты маршрута .

63
00:04:19,745 --> 00:04:25,185
Такая же логика применима как к промо-роутеру, так и к роутеру лидера.

64
00:04:25,185 --> 00:04:30,339
Теперь, когда вы включаете такой параметр запроса в URL-адрес,

65
00:04:30,339 --> 00:04:34,695
как наша серверная сторона сможет извлечь этот параметр запроса?

66
00:04:34,695 --> 00:04:35,980
Таким образом, это где,

67
00:04:35,980 --> 00:04:42,590
когда входящий запрос имеет этот параметр запроса, прикрепленный к входящему URL-адресу,

68
00:04:42,590 --> 00:04:47,375
экспресс-сервер автоматически обработает его и превратит его в

69
00:04:47,375 --> 00:04:54,445
объект JSON, который загружается в сообщение запроса, поступающее на стороне сервера.

70
00:04:54,445 --> 00:05:00,710
Теперь это доступно на стороне сервера в виде req.query.

71
00:05:00,710 --> 00:05:06,545
Таким образом, любые параметры запроса, которые вы включите в URL-адрес, будут превращены в

72
00:05:06,545 --> 00:05:11,480
соответствующие объекты JSON с набором информации, как

73
00:05:11,480 --> 00:05:16,880
показано здесь, а затем загружены в объект запроса на стороне сервера.

74
00:05:16,880 --> 00:05:19,940
Таким образом, используя req.query на стороне сервера,

75
00:05:19,940 --> 00:05:23,625
мы сможем получить эти параметры запроса.

76
00:05:23,625 --> 00:05:27,935
Итак, когда вы выполняете запрос get на стороне сервера, вы говорите

77
00:05:27,935 --> 00:05:34,115
dishes.find, а затем включаете req.query в поиск.

78
00:05:34,115 --> 00:05:38,960
Таким образом, когда MongoDB

79
00:05:38,960 --> 00:05:44,120
запрашивается, то только те записи или только те документы, для

80
00:05:44,120 --> 00:05:50,390
которых избранное установлено в true, будут извлечены из MongoDB и переданы обратно

81
00:05:50,390 --> 00:05:57,020
в этот метод получения здесь, а затем могут быть возвращены на стороне клиента.

82
00:05:57,020 --> 00:06:05,270
Таким образом, это так же просто, как и в обработке параметров запроса на нашей стороне сервера.

83
00:06:05,270 --> 00:06:10,645
Итак, это обновление мы сделаем как с маршрутизатором тарелки,

84
00:06:10,645 --> 00:06:16,880
промо-роутером, так и с ведущим маршрутизатором на нашей стороне сервера.

85
00:06:16,880 --> 00:06:18,430
Следующая часть,

86
00:06:18,430 --> 00:06:20,545
конечно же, Аутентификация пользователей.

87
00:06:20,545 --> 00:06:22,060
Итак, как мы поняли,

88
00:06:22,060 --> 00:06:24,150
на стороне сервера у нас уже есть

89
00:06:24,150 --> 00:06:29,450
эти конечные точки REST API, которые полезны для аутентификации пользователей,

90
00:06:29,450 --> 00:06:33,260
в частности, когда вы делаете сообщение, чтобы

91
00:06:33,260 --> 00:06:37,100
слэш пользователей логин с именем пользователя и паролем,

92
00:06:37,100 --> 00:06:41,675
тогда вы сможете аутентифицировать пользователя на сервере сторона.

93
00:06:41,675 --> 00:06:46,080
Теперь, когда пользователь успешно прошел проверку подлинности на стороне сервера,

94
00:06:46,080 --> 00:06:50,584
то ответное сообщение, поступающее со стороны сервера, будет включать

95
00:06:50,584 --> 00:06:58,880
JSON Web Token в тело ответа входящего ответного сообщения со стороны сервера.

96
00:06:58,880 --> 00:07:00,350
Итак, на стороне клиента,

97
00:07:00,350 --> 00:07:04,700
мы должны иметь возможность извлечь этот токен, а затем использовать этот токен впоследствии.

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

99
00:07:08,210 --> 00:07:12,560
стороны сервера и пользователь успешно аутентифицирован на стороне сервера,

100
00:07:12,560 --> 00:07:15,220
ответное сообщение будет содержать JSON Web Token,

101
00:07:15,220 --> 00:07:16,950
который должен быть извлечен,

102
00:07:16,950 --> 00:07:20,780
а затем клиент должен включить этот JSON Web Token

103
00:07:20,780 --> 00:07:26,200
в для каждого исходящего запроса со стороны клиента.

104
00:07:26,200 --> 00:07:31,205
Это достигается путем сохранения веб-токена JSON в локальном хранилище.

105
00:07:31,205 --> 00:07:35,155
После этого, для каждого запроса выборки, которые мы

106
00:07:35,155 --> 00:07:40,365
выдаем, мы можем настроить заголовок авторизации, чтобы содержать JSON Web Token.

107
00:07:40,365 --> 00:07:43,815
Теперь процесс выхода из системы довольно прост,

108
00:07:43,815 --> 00:07:47,865
если мы уничтожим JSON Web Token, который у нас есть на стороне

109
00:07:47,865 --> 00:07:51,210
клиента, то клиент больше не сможет получить доступ к серверу.

110
00:07:51,210 --> 00:07:53,930
Таким образом, это так же просто, как просто уничтожить

111
00:07:53,930 --> 00:07:58,180
JSON Web Token на стороне клиента для выхода из этого клиента.

112
00:07:58,180 --> 00:08:00,530
Итак, учитывая это понимание,

113
00:08:00,530 --> 00:08:04,175
давайте посмотрим шаги, которые участвуют

114
00:08:04,175 --> 00:08:09,840
в выполнении аутентификации пользователя при обработке аутентификации пользователя на стороне клиента.

115
00:08:09,840 --> 00:08:13,085
Таким образом, чтобы обработать аутентификацию пользователя на стороне

116
00:08:13,085 --> 00:08:19,000
клиента, клиент отправит почтовый запрос в конечную точку входа косой черты пользователей,

117
00:08:19,000 --> 00:08:24,190
а тело почтового запроса будет содержать имя пользователя и пароль.

118
00:08:24,190 --> 00:08:26,720
Мы используем аутентификацию для входа в систему в этом случае.

119
00:08:26,720 --> 00:08:28,695
Теперь, для аутентификации Facebook, опять же,

120
00:08:28,695 --> 00:08:32,425
это другая настройка, которую я не собираюсь обсуждать прямо сейчас.

121
00:08:32,425 --> 00:08:35,570
Но тело запроса, как вы видите для

122
00:08:35,570 --> 00:08:38,780
локальной аутентификации, будет содержать имя пользователя и пароль.

123
00:08:38,780 --> 00:08:43,220
Таким образом, когда пользователь успешно прошел проверку подлинности на стороне сервера,

124
00:08:43,220 --> 00:08:46,460
сервер ответит обратно

125
00:08:46,460 --> 00:08:51,490
клиенту, включив в ответное сообщение JSON Web Token.

126
00:08:51,490 --> 00:08:56,150
Таким образом, когда клиент получает ответное сообщение со стороны сервера,

127
00:08:56,150 --> 00:09:00,320
клиенту придется захватить этот веб-токен JSON, а затем

128
00:09:00,320 --> 00:09:05,080
сохранить веб-токен JSON в локальном хранилище на стороне клиента.

129
00:09:05,080 --> 00:09:11,300
После этого клиент должен включать этот токен в каждый исходящий запрос.

130
00:09:11,300 --> 00:09:14,495
Итак, как это делается на стороне клиента?

131
00:09:14,495 --> 00:09:20,285
Прежде всего, нам нужно сохранить JSON Web Token в локальное хранилище.

132
00:09:20,285 --> 00:09:25,670
Теперь это выполняется внутри создателя действия, который обрабатывает процесс входа пользователя.

133
00:09:25,670 --> 00:09:32,685
Таким образом, когда сообщение делается на сервер от создателя индукции на стороне клиента,

134
00:09:32,685 --> 00:09:36,020
то ответное сообщение будет содержать токен,

135
00:09:36,020 --> 00:09:41,540
и этот токен сохраняется в создателе действия, который обрабатывает процесс входа пользователя.

136
00:09:41,540 --> 00:09:45,875
Теперь после этого, когда выполняется любой запрос выборки,

137
00:09:45,875 --> 00:09:52,829
мы можем легко установить заголовок авторизации в исходящем запросе выборки.

138
00:09:52,829 --> 00:09:56,005
Теперь, как только клиент выходит из системы,

139
00:09:56,005 --> 00:09:59,930
JSON Web Token будет уничтожен на стороне клиента.

140
00:09:59,930 --> 00:10:03,050
Поэтому после этого исходящие запросы

141
00:10:03,050 --> 00:10:07,490
больше не будут содержать JSON Web Token, потому что веб-токен JSON не существует на стороне клиента.

142
00:10:07,490 --> 00:10:10,790
Таким образом, пользователь теряет аутентификацию.

143
00:10:10,790 --> 00:10:17,455
Таким образом, мы будем обрабатывать логин и процесс выхода из системы на стороне клиента.

144
00:10:17,455 --> 00:10:21,890
Общаясь с сервером, а затем получая веб-токен JSON, а

145
00:10:21,890 --> 00:10:26,185
затем включив веб-токен JSON в каждый исходящий запрос.

146
00:10:26,185 --> 00:10:31,570
Теперь, с таким пониманием того, как клиент и сервер будут взаимодействовать,

147
00:10:31,570 --> 00:10:35,540
давайте перейдем к следующим двум упражнениям.

148
00:10:35,540 --> 00:10:40,410
Во-первых, мы обновим серверную сторону с несколькими добавлениями

149
00:10:40,410 --> 00:10:45,550
, чтобы она могла хорошо интегрироваться с нашей клиентской стороной.

150
00:10:45,550 --> 00:10:50,075
После этого мы обновим клиентскую сторону или, вернее, я дам вам

151
00:10:50,075 --> 00:10:54,200
полноценное клиентское приложение, которое я взял

152
00:10:54,200 --> 00:10:58,875
из более ранней силы реагирования и адаптировал его, обновил его.

153
00:10:58,875 --> 00:11:03,080
Итак, мы рассмотрим оба этих вопроса в следующих двух упражнениях,

154
00:11:03,080 --> 00:11:09,460
и в конце вы поймете, как интегрировать клиентскую и серверную сторону.