1. Цифровой диалог
жүктеу/скачать 336.4 Kb.
|
- Бұл бет үшін навигация:
- user_id есть в web_users и есть в запросе
- user_id нет в web_users
| user_id есть в web_users, но нет в запросе:
о Это означает, что пользователь веб-сайта привязан к чат-боту. Возвращаем user_id в ответе, чтобы веб-сайт авторизовал пользователя; user_id есть в web_users и есть в запросе: о Если user_id совпадают, то это означает, пользователь уже авторизован на сайте и бот привязан к его аккаунте. Предлагаем вернуться на сайт; о Если user_id отличаются, то скорее всего пользователь пытается привязать свой новый аккаунт на сайте к боту, а тот уже привязан к другому аккаунте на сайте. Решите как хотите обработать эту исключительную ситуацию, например, предложите пользователю варианты на выбор: отвязать старый аккаунт и привязать новый, оставить привязку к другому аккаунту; user_id нет в web_users: о Если в запросе нет user_id, то это означает пользователь входит на сайте через бота и скорее всего аккаунта на сайте у него тоже нет, но это не точно; о В идеале нужно поискать наличие аккаунта, например, запросив регистрационные данные и выполнив поиск по API; о В самом простом сценарии, мы полагаем, что пользователь входит на сайт через чат-бот и одновременно регистрирует аккаунт на сайте. Авторизация без ввода PIN Для простых случаев, например, когда нам нужно показать форму ввода, принять значения, закрыть ее и вернуться в бота, мы можем не спрашивать PIN кода при переходе на сайт. Сайт может доверять хэш токену, который получили в GET, идентифицируя по нему пользователя без проверки PIN кода. Это менее безопасный вариант, в котором есть риск, что Алиса свою ссылку со своим хэшом может переслать другому пользователю Боту, который откроет ее и будет идентифицирован на сайте под Алисой. Это допустимо в некоторых не критичных случаях, например, вы можете использовать ссылку для ввода данных, которая живет не более 1 часа. Повышение безопасности авторизации Опционально, вы можете улучшить безопасность, добавив дополнительные проверки, например, время жизни PIN-кода или сделав одноразовый ввод кода. Обработайте нужные вам ситуации и верните сайту ответ о результате проверки. Что дальше? А дальше все зависит от ваших конкретных задач и проблем. Теперь когда у вас в таблице соответствия есть взаимно-однозначная связь между ID персоны в боте и ID пользователя на сайте, вы можете как работать с сервисами веб-сайта через чат-бот от имени пользователя сайта, так и со стороны сайта инициировать в чат-боте те или иные действия для пользователя. Также, мы рекомендуем разместить в боте функцию выхода из аккаунта, а на сайте опции для отвязки и привязки бота заново. Асинхронные коммуникации или зачем чат-боту нужен RESTful интерфейс RESTful подход подразумевает, что обмен данными между системами происходит в режиме stateless т.е. без сохранения состояния, что означает информация о клиенте не сохраняется между запросами на получение, и каждый запрос является отдельным и не связанным. Поскольку коммуникация с чат-ботом носит асинхронный характер, т. е. время между очередными запросами через чат-бота может быть очень большим и мы не можем заранее знать когда пользователь вернется, чтобы продолжить диалог и не знаем когда он завершит сеанс, значит мы не можем создавать сеанс для каждого пользователя, идентифицироваться во внешней системе должна платформа Metabot и обслуживать поток запросов от всех пользователей бота. На практике вы будете сталкиваться с устаревшими системами и сервисами, которые нельзя назвать RESTful. Вы можете столкнуться с устаревшим подходом к проектированию API взаимодействия когда сессия пользователя истекает через некоторое время и ее нужно обновлять. Если разработчики системы не могут изменить API и у вас нет возможности сделать доработку, то реализовывайте работу с API в два шага: первым шагом создавайте сессию, которую обновляйте, если она истекла, перед следующем запросом, а вторым шагом выполняйте нужный вам запрос. Что такое API? API (Application Programming Interface или интерфейс для прикладного программирования) — это набор определений и протоколов для создания и интеграции прикладного программного обеспечения. Иногда его называют контрактом между поставщиком информации и потребителем информации, устанавливающим контент, требуемый от потребителя (вызов), и контент, требуемый поставщиков (ответ). Например, дизайн API для погодной службы может указывать, что потребитель должен предоставить почтовый индекс, а производитель должен ответить двумя частями: первая — высокая температура, а вторая — низкая. Другими словами, если вы хотите взаимодействовать с компьютером или системой для получения информации или выполнения какой-либо функции, API поможет вам передать то, что вы хотите, этой системе, чтобы она могла понять и выполнить запрос. Вы можете думать об API как о посреднике между пользователями или клиентами и ресурсами или веб-сервисами, которые они хотят получить. Это также способ для организации обмена ресурсами и информацией, сохраняя при этом безопасность, контроль и аутентификацию, определяя, кто и к чему получает доступ. Еще одно преимущество API заключается в том, что вам не нужно знать особенности кэширования — как извлекается ваш ресурс или откуда он берется. Что такое REST? REST (Representational State Transfer или передача репрезентативного состояния) — это набор архитектурных ограничений, а не протокол или стандарт. Разработчики API могут реализовать REST различными способами. Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful». REST API (также известный как RESTful API) — это интерфейс прикладного программирования, который соответствует ограничениям архитектурного стиля REST и позволяет взаимодействовать с веб-службами. REST означает передачу репрезентативного состояния (Representational State Transfer) и был создан компьютерным ученым Роем Филдингом. Когда клиентский запрос выполняется через RESTful API, он передает представление о состоянии ресурса запрашивающей стороне или конечной точке. Эта информация или представление доставляется в одном из нескольких форматов через HTTP: JSON (обозначение объектов Javascript), HTML, XLT, Python, PHP или обычный текст. JSON является наиболее популярным форматом файлов для использования, потому что, несмотря на свое название, он не зависит от языка, а также удобен для чтения как людьми, так и машинами. Еще кое-что, о чем следует помнить: заголовки и параметры также важны в HTTP-методах HTTP-запроса RESTful API, поскольку они содержат важную информацию об идентификаторе в отношении метаданных запроса, авторизации, универсального идентификатора ресурса (URI), кэширования, файлов cookie и т. д. Существуют заголовки запросов и заголовки ответов, каждый из которых имеет собственную информацию о HTTP-соединении и коды состояния. Чтобы API считался RESTful, он должен соответствовать следующим критериям: Архитектура клиент-сервер, состоящая из клиентов, серверов и ресурсов, с запросами, управляемыми через HTTP; с Связь клиент-сервер без сохранения состояния (stateless), что означает информация о клиенте не сохраняется между запросами на получение, и каждый запрос является отдельным и не связанным; Кэшируемые данные, которые оптимизируют взаимодействие клиент-сервер; Единый интерфейс между компонентами, чтобы информация передавалась в стандартном виде. Это требует, чтобы: Запрашиваемые ресурсы были идентифицируемы и отделены от представлений,отправленных клиенту; Ресурсы могли управляться клиентом через представление, которое они получают, потому что представление содержит достаточно информации для этого; Самоописательные сообщения, возвращаемые клиенту, содержали достаточно информации, чтобы описать, как клиент должен их обрабатывать; Гипертекст/гипермедиа доступны, что означает, что после доступа к ресурсу клиент должен иметь возможность использовать гиперссылки, чтобы найти все другие доступные в настоящее время действия, которые он может предпринять; Многоуровневая система, организующая каждый тип серверов (отвечающих за безопасность, балансировку нагрузки и т. д.), включающая поиск запрашиваемой информации в виде иерархий, невидимых для клиента; Код по запросу (необязательно): возможность отправлять исполняемый код с сервера клиенту по запросу, расширяя функциональные возможности клиента. жүктеу/скачать 336.4 Kb. Достарыңызбен бөлісу:
|