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

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

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

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

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

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

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

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

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

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

Вот отрывок из основополагающего вывода REST Роя Филдинга:

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

Вот в чем дело: REST - это связь с отслеживанием состояния по протоколу без отслеживания состояния. Дело не в том, что REST не имеет состояния. WebForms позволяет сохранять состояние между запросами. Зачем это нужно? Это позволяет вам выполнять такие действия, как сортировка элементов в списке с помощью кнопок вверх / вниз, без необходимости обновлять базовый ресурс при каждом щелчке. Тебе это не нужно. Вы можете просто ПОСТАВИТЬ представление ресурса, чтобы оно выглядело правильным, или использовать JavaScript для редактирования вашего представления, а затем выполнить ПОСТАВЛЕНИЕ в конце, когда вы будете удовлетворены. (Обратите внимание, что я использовал 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).

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

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