Являются ли пути RESTful подходящими для настроек сеанса?

Question

У меня дилемма.

Мое веб-приложение имеет дело с такими объектами, как люди, места, активы (например, изображения), теги и т. Д., Для которых я использую маршруты RESTful, сгенерированные map.resources в моих маршрутах. Rb.

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

Для этого я создал SessionController и связанные с ним маршруты отдыха с map.resource. Метод update принимает параметры, такие как asset_type, view_type и owner_id, и сохраняет их в объекте сеанса. Затем AssetController # index использует эти значения, чтобы выбрать данные для отображения и правильное представление.

Проблема, с которой я столкнулся, заключается в том, что мне также нужно иметь возможность публиковать URL-адреса, например "http://www.foo.com/assets?user_id=10&tag_id=185&type=video&sort=recent" - для отправки по электронной почте и т. Д.

Параметры запроса переопределяют любые параметры, сохраненные в текущем сеансе. Они также должны быть липкими, в противном случае принцип «уходи и возвращайся в прежнее положение» нарушается. Это означает, что AssetController # index должен объединить любые параметры запроса с текущими настройками сеанса и сохранить объединенный результат обратно в сеанс.

Так что теперь у меня есть 2 способа сделать одно и то же, что не выглядит очень СУХОЙ.

Мне не нравится сессия с таким шизофреническим качеством, но она, безусловно, упрощает возможность использования формы для выбора порядка сортировки, настройки сложных параметров фильтрации и т. Д.

Не ошибаюсь ли я, что Сессия рассматривается как ресурс, на который нужно ПОСТАВИТЬСЯ? Я был бы признателен за любые указания, которые вы можете дать мне.

Answer 1

Теоретически, вы совершенно правы.REST имеет ограничение без сохранения состояния, объясненное здесь Филдингом («изобретателем» REST).Фактически, если вы хотите придерживаться его REST-предложения, у вас не должно быть никаких «липких» вариантов вообще.Это означает, что параметры должны передаваться при каждом запросе, а не извлекаться из объекта сеанса, таким образом, вы будете иметь согласованный подход в двух описанных вами случаях.

Answer 2

Другой способ, позволяющий без сохранения состояния, это создать ключ для этих местоположений на карте и сохранить их в каком-то постоянном хранилище на стороне сервера. Текущий пользователь может быть строкой, а затем, если они перейдут на другой URL-адрес, представляющий другое местоположение, вы можете объединить две строки из БД, а затем создать новый ключ и отправить их по этому URL-адресу (я имею смысл ?). Аспект без состояния просто означает, что вы не можете хранить вещи на стороне клиента (например, куки / сеансы) - это не значит, что действия клиента не могут изменить состояние сервера для будущих запросов.