Теперь, когда мы завершили реализацию
REST API сервера с использованием Express и MongoDB в этом курсе,
следующая немедленная мысль, которая может возникнуть в вашем уме,
так как мы уже разработали клиентские приложения на предыдущих курсах,
как мы интегрируем их вместе, чтобы наши может
взаимодействовать с полноценным REST API сервером, который мы разработали в этом курсе?
Итак, это то, что мы рассмотрим в
этой лекции и двух упражнений, которые следуют за этой лекцией.
Итак, в конце этого урока
у вас будет React Client, который будет
иметь возможность общаться с сервером, который вы только что разработали в
этом курсе, и иметь возможность поддерживать
полноценное представление на стороне клиента всего нашего приложения.
Таким образом, мы увидим, что мы разработали
полное
приложение от конца до конца от клиента до стороны сервера в этом курсе.
Для интеграции клиента и сервера,
как мы поняли, наш сервер уже
реализован для поддержки полноценного REST API.
С нашей клиентской стороны,
будь то угловой клиент,
ионный клиент или собственный клиент сценария,
все они взаимодействуют с сервером, используя конечные точки REST API.
Таким образом, когда клиент отправляет запрос на сервер в конечной точке REST API,
сервер будет отвечать с соответствующими данными JSON обратно клиенту.
Затем клиент может использовать данные JSON для визуализации представлений для пользователя.
Таким образом, учитывая такое понимание связи между клиентом и сервером,
интеграция должна быть достаточно простой.
Теперь, когда у нас есть аутентификация пользователя, встроенная в нашу серверную сторону,
нам нужно модифицировать наши клиентские приложения,
чтобы они могли выполнять пользовательскую аутентификацию
на стороне сервера, разместив регистрационную информацию на сервере, а затем
получив токен аутентификации со
стороны сервера и затем взаимодействовать с сервером,
включая токен аутентификации в заголовке сообщений запроса.
Таким образом, все это означает, что нам нужно сделать небольшие корректировки как для
клиента, так и для сервера, чтобы они могли общаться друг с другом.
Один аспект, с которым я не сталкивался в упражнении ранее,
заключается в том, как сервер будет обрабатывать параметры запроса, которые приходят со стороны клиента.
Таким образом, как мы поняли,
когда клиентская сторона отправляет запрос на
избранное блюдо или избранного лидера или популярного продвижения,
мы увидели, что URL включает в себя,
функция знака вопроса блюда равна
true в URL-адресе запроса, который приходит со стороны клиента.
Теперь, в данных на стороне сервера,
мы уже видели, что блюдо,
продвижение или лидер включает флаг уже в данных JSON.
Таким образом, когда этот запрос приходит на сторону сервера,
то сервер должен иметь возможность извлечь
этот параметр запроса из входящего запроса, а затем
соответствующим образом выполнить запрос
MongoDB, а затем получить только результаты, где этот флаг установлен в true.
Таким образом, чтобы сделать это, как мы видели,
URL, который используется для отправки запроса на сервер, является,
косой черты блюда вопросительный знак признакам равен true.
Таким образом, мы будем поставлять параметры запроса на нашу сторону сервера.
Теперь, кроме того, когда эта информация получена на стороне сервера,
теперь мы видели, что раньше, когда мы сделали запрос на получение на стороне сервера,
мы просто сказали блюда найти, а затем мы найдем
все блюда, а затем вернем их, когда
запрос получить отправляется на блюдо маршрутизатора косой черты маршрута .
Такая же логика применима как к промо-роутеру, так и к роутеру лидера.
Теперь, когда вы включаете такой параметр запроса в URL-адрес,
как наша серверная сторона сможет извлечь этот параметр запроса?
Таким образом, это где,
когда входящий запрос имеет этот параметр запроса, прикрепленный к входящему URL-адресу,
экспресс-сервер автоматически обработает его и превратит его в
объект JSON, который загружается в сообщение запроса, поступающее на стороне сервера.
Теперь это доступно на стороне сервера в виде req.query.
Таким образом, любые параметры запроса, которые вы включите в URL-адрес, будут превращены в
соответствующие объекты JSON с набором информации, как
показано здесь, а затем загружены в объект запроса на стороне сервера.
Таким образом, используя req.query на стороне сервера,
мы сможем получить эти параметры запроса.
Итак, когда вы выполняете запрос get на стороне сервера, вы говорите
dishes.find, а затем включаете req.query в поиск.
Таким образом, когда MongoDB
запрашивается, то только те записи или только те документы, для
которых избранное установлено в true, будут извлечены из MongoDB и переданы обратно
в этот метод получения здесь, а затем могут быть возвращены на стороне клиента.
Таким образом, это так же просто, как и в обработке параметров запроса на нашей стороне сервера.
Итак, это обновление мы сделаем как с маршрутизатором тарелки,
промо-роутером, так и с ведущим маршрутизатором на нашей стороне сервера.
Следующая часть,
конечно же, Аутентификация пользователей.
Итак, как мы поняли,
на стороне сервера у нас уже есть
эти конечные точки REST API, которые полезны для аутентификации пользователей,
в частности, когда вы делаете сообщение, чтобы
слэш пользователей логин с именем пользователя и паролем,
тогда вы сможете аутентифицировать пользователя на сервере сторона.
Теперь, когда пользователь успешно прошел проверку подлинности на стороне сервера,
то ответное сообщение, поступающее со стороны сервера, будет включать
JSON Web Token в тело ответа входящего ответного сообщения со стороны сервера.
Итак, на стороне клиента,
мы должны иметь возможность извлечь этот токен, а затем использовать этот токен впоследствии.
Таким образом, когда клиент получает ответное сообщение со
стороны сервера и пользователь успешно аутентифицирован на стороне сервера,
ответное сообщение будет содержать JSON Web Token,
который должен быть извлечен,
а затем клиент должен включить этот JSON Web Token
в для каждого исходящего запроса со стороны клиента.
Это достигается путем сохранения веб-токена JSON в локальном хранилище.
После этого, для каждого запроса выборки, которые мы
выдаем, мы можем настроить заголовок авторизации, чтобы содержать JSON Web Token.
Теперь процесс выхода из системы довольно прост,
если мы уничтожим JSON Web Token, который у нас есть на стороне
клиента, то клиент больше не сможет получить доступ к серверу.
Таким образом, это так же просто, как просто уничтожить
JSON Web Token на стороне клиента для выхода из этого клиента.
Итак, учитывая это понимание,
давайте посмотрим шаги, которые участвуют
в выполнении аутентификации пользователя при обработке аутентификации пользователя на стороне клиента.
Таким образом, чтобы обработать аутентификацию пользователя на стороне
клиента, клиент отправит почтовый запрос в конечную точку входа косой черты пользователей,
а тело почтового запроса будет содержать имя пользователя и пароль.
Мы используем аутентификацию для входа в систему в этом случае.
Теперь, для аутентификации Facebook, опять же,
это другая настройка, которую я не собираюсь обсуждать прямо сейчас.
Но тело запроса, как вы видите для
локальной аутентификации, будет содержать имя пользователя и пароль.
Таким образом, когда пользователь успешно прошел проверку подлинности на стороне сервера,
сервер ответит обратно
клиенту, включив в ответное сообщение JSON Web Token.
Таким образом, когда клиент получает ответное сообщение со стороны сервера,
клиенту придется захватить этот веб-токен JSON, а затем
сохранить веб-токен JSON в локальном хранилище на стороне клиента.
После этого клиент должен включать этот токен в каждый исходящий запрос.
Итак, как это делается на стороне клиента?
Прежде всего, нам нужно сохранить JSON Web Token в локальное хранилище.
Теперь это выполняется внутри создателя действия, который обрабатывает процесс входа пользователя.
Таким образом, когда сообщение делается на сервер от создателя индукции на стороне клиента,
то ответное сообщение будет содержать токен,
и этот токен сохраняется в создателе действия, который обрабатывает процесс входа пользователя.
Теперь после этого, когда выполняется любой запрос выборки,
мы можем легко установить заголовок авторизации в исходящем запросе выборки.
Теперь, как только клиент выходит из системы,
JSON Web Token будет уничтожен на стороне клиента.
Поэтому после этого исходящие запросы
больше не будут содержать JSON Web Token, потому что веб-токен JSON не существует на стороне клиента.
Таким образом, пользователь теряет аутентификацию.
Таким образом, мы будем обрабатывать логин и процесс выхода из системы на стороне клиента.
Общаясь с сервером, а затем получая веб-токен JSON, а
затем включив веб-токен JSON в каждый исходящий запрос.
Теперь, с таким пониманием того, как клиент и сервер будут взаимодействовать,
давайте перейдем к следующим двум упражнениям.
Во-первых, мы обновим серверную сторону с несколькими добавлениями
, чтобы она могла хорошо интегрироваться с нашей клиентской стороной.
После этого мы обновим клиентскую сторону или, вернее, я дам вам
полноценное клиентское приложение, которое я взял
из более ранней силы реагирования и адаптировал его, обновил его.
Итак, мы рассмотрим оба этих вопроса в следующих двух упражнениях,
и в конце вы поймете, как интегрировать клиентскую и серверную сторону.