Как мне сделать свое веб-приложение не имеющим состояния, но при этом сделать что-то полезное?

Question

Я видел этот совет ...

в идеале сеть должна следовать принципу REST и полностью не иметь состояния.Поэтому один URL должен идентифицировать один ресурс, без необходимости вести историю навигации каждого пользователя.

... и я прочитал страницу Википедии http://en.wikipedia.org/wiki/REST, и это действительно звучит хорошо, но я не понимаю, как на самом деле это реализовать.Я работаю в ASP .NET Webforms, а не MVC.

Например, в приложении, которое я собираюсь создать - мне нужно, чтобы мой пользователь вошел в систему, прежде чем я позволю им что-либо делать.Есть несколько обручей, через которые они должны прыгнуть, прежде чем им позволят сделать много полезного - например, Принять Т и С и подтвердить, что их основные детали не изменились.Наконец, им разрешено делать то, что они действительно хотят, как BuyAProduct!

Мне кажется (я из ТЯЖЕЛЫГО мира состояний богатого клиента), что мне нужно состояние, чтобы записать то, что они сделали, и сделать вывод из этогочто им разрешено делать.Я не понимаю, как я могу поддержать их (скажем) закладкой URI BuyAProduct.Когда они приходят к закладке, как я узнаю, вошли ли они в систему и согласились ли они с Т и С, и если они должным образом проверили свои основные данные?

Мне нравится идея, что приложение не имеет состояния, частичнопотому что это, кажется, полностью решает проблему «Какого черта я делаю, когда пользователь нажимает кнопки« Назад »и« Вперед »?»Я не понимаю, как я все еще могу заставить его работать должным образом.Я чувствую, что упускаю что-то действительно фундаментальное в этом.

Answer 1

Совет не предполагает, что приложение должно быть без сохранения состояния, - это предполагает, что ресурсы в приложении должны быть без сохранения состояния.То есть страница с именем «www.mysite.com/resources/123» всегда будет представлять один и тот же ресурс, независимо от того, к какому пользователю он обращается, или вошли в него или нет.

(Фактто, что вы можете отказать в доступе незарегистрированным пользователям, - это отдельная проблема. Дело в том, что сам Uri не полагается на работу с данными конкретного пользователя.)

Например, тип сайтовнарушают это правило те, на которых вы переходите на страницу продукта, отправляете по электронной почте Uri своему другу, и, щелкнув по нему, они видят сообщение «Извините, ваш сеанс истек» или «Этот продукт несуществовать "или подобное.Причина этого заключается в том, что Uri включает в себя что-то определенное для сеанса пользователя на сайте, и если другой пользователь пытается использовать ссылку (или того же пользователя в более позднее время), он больше не действителен.

Таким образом, вам всегда будет нужна некоторая форма состояния для вашего приложения, но где это состояние реализовано, является важным фактором.

Надеюсь, что это поможет пролить немного света!

Answer 2

Если вы хотите создавать веб-формы, это круто.Если вы хотите сделать REST, это тоже круто.Но, пожалуйста, ради любви ко всему святому, пожалуйста, не пытайтесь придерживаться принципов REST с помощью веб-форм.

Просто чтобы прояснить этот момент дальше, я не верю, что веб-формы - мудрый выбор для RESTпотому что концептуальная модель, на которой основаны WebForms, - это та, в которой вы абстрагируетесь от сети.Он был построен, чтобы подражать модели развития VB.

REST охватывает HTTP и распределенную природу веб-приложений.Два подхода не совместимы.

Answer 3

Можно поддерживать состояние ресурса. «Запрет без сохранения состояния» относится только к состоянию сеанса.

Вот выдержка из оригинального REST-вывода Роя Филдинга :

Затем мы добавим ограничение к взаимодействию клиент-сервер: общение должно быть без гражданства по своей природе, как в стиль клиента-состояния-сервера (CSS) раздела 3.4.3 (рисунок 5-3), так что каждый запрос от клиента к серверу должен содержать все информация, необходимая для понимания запроса, и не может принять преимущество любого сохраненного контекста на сервере. Состояние сеанса поэтому держится целиком на клиенте.

Answer 4

Кажется, что cookie является ответом на ваш вопрос.Вы можете использовать провайдера аутентификации .net, который установит cookie-файл, который ваше приложение может проверить и требовать наличия, если они что-то покупают.

То, чего вы хотите избежать, - это сохранитьих представление состояния на сервере, также называемое cookie сессии.Это усложнит масштабирование.

Answer 5

Вот в чем дело: REST - это обмен данными с отслеживанием состояния по протоколу без учета состояния. Дело не в том, что REST не имеет статуса. WebForms позволяет вам сохранять состояние между запросами. Почему это необходимо? Это позволяет вам выполнять такие вещи, как сортировка элементов в списке с помощью кнопок вверх / вниз, без необходимости обновлять базовый ресурс при каждом нажатии. Тебе это не нужно. Вы можете просто поставить представление ресурса, чтобы оно выглядело правильно, или использовать JavaScript для редактирования своего представления, а затем сделать PUT в конце, как только вы будете удовлетворены. (Обратите внимание, что я использовал PUT, а не POST. То, что вы действительно делаете, это замените представление так, чтобы будущие GET получали правильное состояние .)

WebForms использует POST для всего. Вы должны отправлять только URL-адреса при создании нового элемента и не знаете, где он будет жить. Если вы знаете его URL, то вы должны использовать PUT для создания или замены. Если вам нужны промежуточные шаги, скажем, для корзины покупок, вам следует создать представления ресурсов для этих промежуточных шагов. Ваш браузер и сервер обмениваются данными, передавая друг другу полные представления. Это простая передача запроса / ответа.

WebForms не поощряют это. Вы можете создавать системы RESTful в WebForms, но модель по умолчанию оттолкнет вас от нее к подходу RPC. Я могу придумать два пути решения этой проблемы: Front Controller (в этом случае вы действительно должны рассмотреть MVC) или использование файлов .ashx практически для всего. Модель Postback довольно хорошо уничтожает любую реальную надежду на выполнение настоящего REST с реальными WebForms / .aspx (то есть PUT и DELETE всегда являются POST и, таким образом, дают сбой модели REST).