Как сделать так, чтобы мое веб-приложение не сохраняло состояние, но при этом оставалось полезным?
Я видел этот совет...
в идеале сеть должна следовать принципу REST и быть полностью безгражданской. Поэтому один URL-адрес должен идентифицировать один ресурс без необходимости вести историю навигации каждого пользователя.
... и я прочитал страницу Википедии http://en.wikipedia.org/wiki/REST и это действительно звучит хорошо, но я не понимаю, как на самом деле это реализовать. Я работаю в ASP .NET Webforms НЕ MVC.
Например, в приложении, которое я собираюсь создать - мне нужно, чтобы мой пользователь вошел в систему, прежде чем я позволю ему что-либо сделать. Есть пара обручей, через которые они должны пройти, прежде чем им позволят сделать много полезного - например, принять T и C и подтвердить, что их основные детали не изменились. Наконец, им разрешено делать то, что они действительно хотят, как BuyAProduct!
Мне кажется (я из Тяжелого государства с богатым состоянием клиента Rich), что мне нужно состояние, чтобы записать, что они сделали, и сделать вывод из того, что им разрешено делать. Я не понимаю, как я могу поддержать их (скажем) закладкой URI BuyAProduct. Когда они достигают закладки, как я узнаю, вошли ли они в систему и согласились ли они с Т и С, и если они должным образом проверили свои основные данные?
Мне нравится идея, что приложение не имеет состояния, отчасти потому, что оно, похоже, полностью решает проблему "Какого черта я делаю, когда пользователь нажимает кнопки Назад и Вперед?" Я не понимаю, как я все еще могу заставить его работать должным образом. Я чувствую, что упускаю что-то действительно фундаментальное в этом.
5 ответов
Совет не говорит о том, что приложение должно быть без сохранения состояния - он предполагает, что ресурсы в приложении должны быть без состояния. То есть страница с именем "www.mysite.com/resources/123" всегда будет представлять один и тот же ресурс, независимо от того, к какому пользователю он обращается, и вошли ли они в систему или нет.
(Тот факт, что вы можете запретить доступ не зарегистрированному пользователю, является отдельной проблемой - дело в том, что сам Uri для работы не полагается на данные, специфичные для пользователя.)
Например, сайты, нарушающие это правило, - это сайты, на которых вы переходите на страницу продукта, отправляете Uri по электронной почте своему другу, и, щелкая по нему, они видят сообщение "Извините, ваш сеанс истек" "или" Этот продукт не существует "или аналогичный. Причина этого заключается в том, что Uri включает в себя что-то определенное для сеанса пользователя на сайте, и если другой пользователь пытается использовать ссылку (или того же пользователя в более позднее время), она больше не действительна.
Таким образом, вы всегда будете нуждаться в некоторой форме состояния для вашего приложения, но где это состояние реализовано, является важным фактором.
Надеюсь, что это поможет пролить немного света!
Если вы хотите делать веб-формы, это круто. Если вы хотите сделать REST, это тоже круто. Но, пожалуйста, ради любви ко всему святому, пожалуйста, не пытайтесь придерживаться принципов REST, используя веб-формы.
Просто чтобы прояснить этот момент далее, я не верю, что веб-формы - это разумный выбор для REST, потому что концептуальная модель, на которой основаны веб-формы, - это та, где вы абстрагируетесь от сети. Он был построен, чтобы подражать модели развития VB.
REST охватывает HTTP и распределенную природу веб-приложений. Два подхода не совместимы.
Это нормально для поддержания состояния ресурса. "Запрет без сохранения состояния" относится только к состоянию сеанса.
Вот выдержка из оригинального REST-вывода Роя Филдинга:
Затем мы добавляем ограничение к взаимодействию клиент-сервер: связь должна быть без состояния по своей природе, как в стиле клиент-сервер без состояния (CSS) в разделе 3.4.3 (рисунок 5-3), так что каждый запрос от клиента к Сервер должен содержать всю информацию, необходимую для понимания запроса, и не может использовать какой-либо сохраненный контекст на сервере. Поэтому состояние сеанса полностью сохраняется на клиенте.
Вот в чем дело: REST - это связь с состоянием по протоколу без учета состояния. Дело не в том, что REST не имеет статуса. WebForms позволяет вам сохранять состояние между запросами. Почему это необходимо? Это позволяет вам делать такие вещи, как сортировка элементов в списке с помощью кнопок вверх / вниз, без необходимости обновлять базовый ресурс при каждом нажатии. Тебе это не нужно. Вы можете просто положить представление ресурса, чтобы оно выглядело правильно, или использовать JavaScript для редактирования своего представления, а затем выполнить PUT в конце, как только вы будете удовлетворены. (Обратите внимание, что я использовал PUT, а не POST. Что вы на самом деле делаете, так это заменяете представление, чтобы будущие GET возвращали правильное состояние.)
WebForms использует POST для всего. Вы должны отправлять только URL-адреса, когда вы создаете новый элемент и не знаете, где он будет жить. Если вы знаете его URL, то вы должны использовать PUT для создания или замены. Если вам нужны промежуточные шаги, скажем, для корзины покупок, вам следует создать представления ресурсов для этих промежуточных шагов. Ваш браузер и сервер обмениваются данными, передавая друг другу полные представления. Это простая передача запроса / ответа.
Веб-формы не поощряют это. Вы можете создавать системы RESTful в WebForms, но модель по умолчанию оттолкнет вас от подхода RPC. Я могу придумать два пути решения этой проблемы: Front Controller (в этом случае вы действительно должны рассмотреть MVC) или использование файлов.ashx практически для всего. Модель Postback довольно хорошо уничтожает любую реальную надежду на выполнение настоящего REST с реальными WebForms/.aspx (т. Е. PUT и DELETE всегда являются POST и, таким образом, дают сбой модели REST).
Кажется, cookie - это ответ на ваш вопрос. Вы можете использовать провайдера аутентификации.net, который установит cookie-файл, который ваше приложение может проверить и требовать его наличия, если они что-то покупают.
То, чего вы хотите избежать, - это сохранить их состояние на сервере, то есть файл cookie сеанса. Это усложнит масштабирование.