Теперь, когда мы
завершили реализацию сервера REST API с помощью Express и MongoDB в этом курсе,
следующая немедленная мысль, которая может возникнуть в вашем уме,
так как мы уже разработали клиентские
приложения, будь то угловое приложение, ионное приложение
или Приложение Native Script в предыдущих курсах,
как мы интегрируем их вместе, чтобы наше клиентское приложение могло
взаимодействовать с полнофункциональным REST API сервером, который мы разработали в этом курсе?
Итак, это то, что мы рассмотрим на этом уроке,
в этой лекции, и в двух упражнениях, которые следуют за этой лекцией.
Таким образом, в конце этого урока
у вас будет угловой клиент, который мы
сможем общаться с сервером, который вы только что разработали в
этом курсе, и иметь возможность поддерживать
полноценное представление на стороне клиента всего нашего приложения.
Таким образом, мы увидим, что мы разработали
полное приложение от конца до конца от клиента до стороны сервера.
Аналогичный подход также может быть использован с
вашим Ionic клиентом или с вашим клиентом Native скриптов,
учитывая тот факт, что как Ionic, так и Native скрипты были
разработаны с помощью движка Angular за кулисами.
Таким образом, выполнение аналогичного набора шагов должно быть в состоянии сделать ваш Ionic клиент, а также
ваш Native скрипт клиент общаться с
сервером API Express plus MongoDB, который мы разработали в этом курсе.
Для интеграции клиента и сервера,
как мы уже поняли,
наш сервер уже реализован для поддержки полноценного REST API.
С нашей клиентской стороны,
будь то угловой клиент,
ионный клиент или собственный клиент сценария,
все они взаимодействуют с сервером, используя конечные точки REST API.
Таким образом, когда клиент отправляет запрос на сервер в конечной точке REST API,
сервер будет отвечать с соответствующими данными JSON обратно клиенту,
и клиент может затем использовать данные JSON для отображения представлений для пользователя.
Таким образом, учитывая такое понимание связи между клиентом и сервером,
интеграция должна быть достаточно простой.
Но теперь, конечно,
когда мы разработали наш Angular или Ionic или клиент NativeScript,
мы не делали полноценную часть аутентификации пользователя,
потому что у нас не было этого на нашем сервере JSON.
Теперь, когда у нас есть аутентификация пользователя, встроенная в нашу серверную сторону,
нам нужно модифицировать наши клиентские приложения,
чтобы они могли выполнять аутентификацию пользователя на стороне сервера,
путем публикации информации для входа на сервер, а затем
получения токена аутентификации со стороны сервера,
и затем, общаясь с сервером, включая
токен аутентификации в заголовке сообщений запроса.
Итак, все это означает, что нам нужно делать
небольшие корректировки как для клиента, так и для сервера,
чтобы они могли общаться друг с другом.
Один аспект, с которым я не сталкивался в упражнении ранее,
заключается в том, как сервер будет обрабатывать параметры запроса, которые приходят со стороны клиента.
Таким образом, как мы поняли,
когда клиентская сторона отправляет запрос на
избранное блюдо или избранного лидера или продвижение функции,
мы увидели, что URL включает блюда,
функция вопросительного знака равна true в
URL-адресе запроса, который приходит со стороны клиента.
Теперь, в данных на стороне сервера,
мы уже видели, что блюдо,
продвижение или лидер,
включает флаг функции уже в данных JSON.
Таким образом, когда этот запрос приходит на сторону сервера,
то сервер должен иметь возможность извлечь этот параметр запроса из входящего запроса,
а затем соответствующим образом выполнить запрос
MongoDB, а затем получить только результаты, где этот флаг установлен в true.
Итак, чтобы сделать это, как мы видели,
URL-адрес, который используется для отправки запроса на сервер, является /dishes? feature=true.
Таким образом, мы будем поставлять параметры запроса на нашу сторону сервера.
Теперь, кроме того, когда эта информация получена на стороне сервера,
теперь, мы видели, что раньше, когда мы делали запрос на получение на стороне сервера,
мы просто сказали, что блюда найти, а затем мы находим все блюда, а затем возвращаем их,
когда запрос get отправляется в DishRouterRoute/.
Такая же логика применима как к промо-роутеру, так и к роутеру лидера.
Теперь, когда вы включаете такой параметр запроса в URL-адрес,
как наша серверная сторона сможет извлечь этот параметр запроса?
Таким образом, это где, когда входящий запрос имеет
этот параметр запроса, прикрепленный к входящему URL-адресу,
экспресс-сервер автоматически обработает его и превратит его в
объект JSON, который загружается в сообщение запроса, поступающее на стороне сервера.
Теперь это доступно на стороне сервера в виде req.query.
Таким образом, любые параметры запроса, которые вы
включили в URL-адрес, будут преобразованы в соответствующие объекты JSON с набором информации, как показано здесь,
а затем загружены в объект запроса на стороне сервера.
Таким образом, используя req.query на стороне сервера,
мы сможем получить эти параметры запроса.
Итак, когда вы выполняете запрос get на стороне сервера,
вы говорите dishes.find, а затем включаете req.query в поиск.
Таким образом, когда MongoDB запрашивается, то
только те записи или только те документы, для которых признакам установлено значение true, будут
извлечены из MongoDB и переданы обратно в этот метод get здесь,
а затем, могут быть возвращены на стороне клиента.
Таким образом, это так же просто, как и в обработке параметров запроса на нашей стороне сервера.
Итак, это обновление мы сделаем как с маршрутизатором тарелки,
промо-роутером, так и с ведущим маршрутизатором на нашей стороне сервера.
Следующая часть, конечно же, аутентификация пользователя.
Таким образом, как мы поняли на стороне сервера, у
нас уже есть эти конечные точки REST API,
которые полезны для аутентификации пользователей.
В частности, когда вы делаете сообщение в/users/login,
с именем пользователя и паролем,
вы сможете аутентифицировать пользователя на стороне сервера.
Теперь, когда пользователь успешно аутентифицирован на стороне сервера,
то ответное сообщение, поступающее со стороны сервера, будет включать
веб-маркер JSON в тело ответа входящего ответного сообщения со стороны сервера.
Итак, на стороне клиента,
мы должны иметь возможность извлечь этот токен, а затем использовать этот токен впоследствии.
Таким образом, когда клиент получает ответное сообщение со
стороны сервера, и пользователь успешно аутентифицирован на стороне сервера,
ответное сообщение будет содержать веб-токен JSON,
который должен быть извлечен, и после этого
клиент должен включить этот веб-токен JSON
в для каждого исходящего запроса со стороны клиента.
Итак, как мы справимся со всем этим набором операций?
Теперь, это где мы будем реализовывать
другую службу, которая будет использоваться на нашей стороне клиента,
в нашем угловом клиенте,
называемом службой аутентификации,
и именно там мы будем обрабатывать все операции входа и выхода из системы.
Теперь процесс выхода из системы довольно прост, но
если мы уничтожим веб-токен JSON, который у нас есть на стороне клиента,
то клиент больше не сможет получить доступ к серверу.
Таким образом, это так же просто, как просто уничтожить
веб-токен JSON на стороне клиента для выхода из этого клиента.
Итак, учитывая это понимание,
давайте посмотрим шаги, которые участвуют
в выполнении аутентификации пользователя и обработки аутентификации пользователя на стороне клиента.
Таким образом, чтобы обработать аутентификацию пользователя на стороне клиента,
клиент отправит почтовый запрос в конечную точку /users/login,
а тело почтового запроса будет содержать имя пользователя и пароль.
Мы используем аутентификацию для входа в систему в этом случае.
Теперь, для аутентификации Facebook снова,
это другая настройка, которую я не собираюсь обсуждать прямо сейчас.
Но тело запроса, как вы увидите для локальной аутентификации,
будет содержать имя пользователя и пароль.
Таким образом, когда пользователь успешно аутентифицирован на стороне сервера,
сервер ответит обратно
клиенту, включив веб-маркер JSON в ответное сообщение.
Таким образом, когда клиент получает ответное сообщение со стороны сервера,
клиенту придется захватить этот веб-токен JSON,
а затем сохранить веб-токен JSON в локальном хранилище на стороне клиента.
После этого клиент должен включать этот токен в каждый исходящий запрос.
Итак, как это делается на стороне клиента?
Прежде всего, конечно,
вам нужно сохранить входящий веб-токен JSON в локальное хранилище,
и это делается в сервисе аутентификации, который мы будем реализовывать на стороне клиента.
Теперь, для каждого исходящего запроса,
клиент будет включать этот токен в заголовок,
заголовок авторизации исходящего запроса.
Итак, как это делается?
Итак, вот где мы собираемся взять помощь перехватчика HTTP,
который поддерживает HttpClient в Angular.
Таким образом, с помощью перехватчика HTTP,
перехватчик позволяет нам перехватывать
каждое исходящее сообщение запроса или даже
перехватывать каждое входящее ответное сообщение, если вы так хотите.
Но в приложении Angular
мы собираемся реализовать перехватчик запросов,
который я проиллюстрирую в упражнении позже.
В перехватчике запросов HTTP,
когда сообщение запроса перехвачено,
каждое исходящее сообщение запроса будет перехвачено, а затем веб-токен JSON
будет вставлен в заголовок авторизации сообщения запроса.
Затем после этого сообщение запроса будет передано на сторону сервера.
Таким образом, каждый исходящий запрос после аутентификации пользователя на стороне сервера,
каждый исходящий запрос со стороны клиента будет нести
веб-токен JSON в заголовке авторизации исходящего запроса.
Теперь, как только клиент выйдет из системы,
веб-токен JSON будет уничтожен на стороне клиента.
Таким образом, после этого исходящие запросы больше не будут содержать веб-токен
JSON, потому что веб-токен JSON не существует на стороне клиента.
Таким образом, пользователь теряет аутентификацию.
Таким образом, мы будем обрабатывать процесс входа и выхода из системы на стороне клиента,
общаясь с сервером,
а затем получать веб-токен JSON,
а затем включать веб-токен JSON в каждый исходящий запрос.
Теперь, с таким пониманием того, как клиент и сервер будут взаимодействовать,
давайте перейдем к следующим двум упражнениям.
Во-первых, мы обновим серверную сторону с несколькими добавлениями,
чтобы она могла хорошо интегрироваться с нашим сайтом клиента.
После этого мы обновим клиентскую сторону или, скорее, я дам вам
полноценное клиентское приложение, которое я
взял из предыдущего углового курса, а затем я обновлю его, что
также дает нам возможность использовать HTTP-перехватчики
как на исходящих запросах, так и на входящие ответные сообщения.
Итак, мы разберемся с ними в следующих двух упражнениях,
а в конце вы
поймете, как интегрировать клиента и серверную сторону.