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