У меня есть новый проект, включающий сборку приложения для Android для сайта туристического клуба. На веб-сайте есть функция входа в систему, после которой пользователь может просматривать доступные походы, подписаться на поход, просматривать других подписчиков, связаться с организатором и т. Д. Исходный сайт основан на базе данных MySQL с передним концом страниц .asp. Большинство данных передается через страницы как параметры GET в строке запроса.Расширение существующего веб-приложения с Android-приложением
Новое в Android-разработке, некоторые вещи действительно озадачивают меня, даже после прочтения нескольких учебников. Я думаю об архитектуре baes на веб-сервисах REST, но есть несколько препятствий для преодоления и выбора.
Помимо использования REST, некоторые другие варианты:
Вызов оригинальные .asp страниц из приложения вместо создания специальной веб-службы. Это оставляет мне гораздо меньше кода для написания, может использоваться исходная бизнес-логика (запросы e.a.), а также система входа в систему (с функцией «запомнить меня» на основе файлов cookie). Недостатком является то, что HTML-код (X) HTML в ответе должен быть проанализирован для отображения в графическом интерфейсе приложения, где большая часть кода ответа является бесполезным балластным кодом. Кроме того, это не очень хорошо с точки зрения архитекторов.
Использование веб-службы на основе SOAP. Я совершенно не знаком с SOAP, и, похоже, он слишком тяжелый для мобильного устройства.
Использование служб REST. Я склоняюсь к этому варианту и сделал некоторые уже работающие сервисы, используя структуру SLIM. Но есть проблемы . Во-первых, REST по определению является апатридом и делает , похоже, не поддерживает сеансы. Но опция «Запомнить меня» - это , необходимая для приложения после входа в систему в первый раз, пользователю не нужно снова входить в систему, если он явно не выйдет из системы.
Но как мы можем достичь этого?
Первый вариант заключается в разработке некоторой системы входа/выхода на сайт клиента, которая сохраняет учетные данные локально до тех пор, пока пользователь не выйдет из системы. И отправка учетных данных с каждым запросом веб-службе в качестве параметров POST или каким-либо образом в заголовке запроса авторизации HTTP, хотя я не знаком с этим.
Второй вариант состоит в том, чтобы немного отклониться от принципов RESt и использовать механизм сеанса в любом случае. После отправки учетных данных веб-службе создается файл cookie и отправляется в клиентское приложение. Дартабаза не может быть расширена, поэтому нет возможности сохранить токен в таблице пользователя. Может быть, usernae/password можно зашифровать и отправить в файл cookie в приложение и расшифровать при каждом последующем запросе?
Я немного потерял в этом и с нетерпением жду серьезных предложений!
Спасибо, и я планирую следовать этой стратегии. Я расширил веб-службы, передав учетные данные имени пользователя и пароля с каждым пользовательским запросом в качестве параметров GET для операций по извлечению данных. И это работает сейчас, хотя и не очень безопасно. Это оставляет проблему, что большинство бизнес-правил должны быть написаны снова, потому что теперь они скрыты за страницами .asp. Было бы здорово, если бы эти бизнес-правила могли быть размещены в одном общем месте, но я думаю, что существующее веб-приложение должно быть переписано в этом случае ... – klausch
Старый поток, но вы решили это с помощью предлагаемого метода? Я делаю что-то подобное, но борюсь с Volley Google, чтобы продолжить сессию ASP – Jammo