Как сделать мой веб-приложение безстоящим, но все же сделать что-то полезное?
Я видел этот совет...
в идеале сеть должна следовать принципу REST и быть полностью без гражданства. Поэтому один URL-адрес должен идентифицировать один ресурс без необходимости вести историю навигации для каждого пользователя.
... и я прочитал страницу Wikipedia http://en.wikipedia.org/wiki/REST, и это действительно звучит хорошо, но я не понимаю, как на самом деле реализовать его. Я работаю в ASP.NET Webforms NOT MVC.
Например, в приложении, которое я собираюсь построить, мне нужен мой пользователь для входа, прежде чем я разрешу им что-либо сделать. Есть пара обручей, с которыми им приходится перепрыгивать, прежде чем им разрешено делать много полезного - например, Accept T и C и подтвердить, что их основные детали не изменились. Наконец им разрешено делать то, что они действительно хотят, как BuyAProduct!
Мне кажется (я из HEAVILY stateful world of the Rich client), что мне нужно состояние, чтобы записать то, что они сделали, и сделать вывод о том, что им разрешено делать. Я не вижу, как я могу их поддержать (скажем), чтобы закладировать UAP BuyAProduct. Когда они прибудут в закладку, как я узнаю, если они вошли в систему, и если они согласились с T и C, и если они послушно проверили свои основные данные?
Мне нравится идея того, что приложение не имеет гражданства, отчасти потому, что он, похоже, полностью решает проблему "Что мне делать, когда пользователь нажимает кнопки" Назад "и" Вперед "? Я не вижу, как я могу заставить его работать правильно. Я чувствую, что мне не хватает чего-то действительно фундаментального в этом отношении.
Ответы
Ответ 1
Совет не предполагает, что приложение должно быть без гражданства - оно предполагает, что ресурсы в приложении должны быть без гражданства. То есть страница, называемая "www.mysite.com/resources/123", всегда будет представлять один и тот же ресурс, независимо от того, какой пользователь обращается к нему или вошел ли он в систему или нет.
(Тот факт, что вы можете отказать в доступе пользователя без входа в систему, является отдельной проблемой - дело в том, что сам Uri не полагается на данные, специфичные для пользователя, для работы.)
Например, те сайты, которые нарушают это правило, - это те, в которых вы переходите на страницу продукта, отправляете по электронной почте Uri своему другу, и, щелкая по нему, они видят сообщение в соответствии с "Извините, ваш сессия истек" или "Этот продукт не существует" или аналогичный. Причина этого в том, что Uri включает в себя что-то конкретное для пользовательского сеанса на сайте, и если другой пользователь пытается использовать ссылку (или тот же самый пользователь в более позднее время), она перестает быть действительной.
Таким образом, вы всегда будете нуждаться в какой-то форме для своего приложения, но там, где это состояние реализовано, является важным фактором.
Надеюсь, что поможет пролить немного света!
Ответ 2
Если вы хотите делать веб-формы, это круто. Если вы хотите сделать REST, что тоже круто. Но, пожалуйста, ради любви ко всему священному, пожалуйста, не пытайтесь придерживаться принципов REST с помощью веб-форм.
Чтобы уточнить этот момент, я не верю, что веб-формы являются разумным выбором для REST, потому что концептуальная модель, на которой основана WebForms, - это та, где вы отвлекаете веб-страницы. Он был создан для эмуляции модели разработки VB.
REST охватывает HTTP и распределенный характер веб-приложений. Эти два подхода несовместимы.
Ответ 3
Здесь вещь: REST - это сообщение об отсутствии сообщений об отсутствии состояния в протоколе без состояния. Это не то, что REST не имеет гражданства. WebForms позволяет сохранять состояние между запросами. Почему это необходимо? Это позволяет вам делать что-то вроде элементов сортировки в списке с помощью кнопок вверх/вниз без необходимости обновлять базовый ресурс при каждом нажатии. Тебе это не нужно. Вы могли бы просто PUT представить представление ресурса, чтобы оно выглядело правильно или использовать 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).
Ответ 4
Файл cookie, похоже, будет ответом на ваш вопрос. Вы можете использовать провайдер проверки подлинности .net, который установит файл cookie, который ваше приложение может проверить и потребовать наличия, если оно что-то хочет купить.
Вещь, которую вы хотите попытаться избежать, заключается в сохранении представления о состоянии на сервере, например, cookie сеанса. Это затруднит масштабирование.
Ответ 5
Это нормально поддерживать состояние ресурса. "Запрет без гражданства" относится только к состоянию сеанса.
Здесь выдержка из Рой Филдинг, основополагающий вывод REST:
Затем добавим ограничение на взаимодействие клиент-сервер: связь должна быть апатридом по своему характеру, как в стиль client-stateless-server (CSS) раздела 3.4.3 (Рисунок 5-3), так что каждый запрос от клиента к серверу должен содержать все информация, необходимая для понимания запроса, и не может принимать преимущество любого сохраненного контекста на сервере. Состояние сеанса поэтому полностью хранится на клиенте.
