Можете ли вы предоставить информацию или ссылки, которые обсуждают использование состояния ресурса в течение сеанса или состояния БД?

Question

Стефан Тилков говорит здесь, где он описывает архитектуру REST в ее основе. Я не наблюдал за всем этим, но в той части, где он говорит о 5 принципах REST (слайды 12-19), он упоминает о поддержании состояния через ресурс (то есть - URI). Его пример - корзина для покупок. Обычно состояние вашей корзины покупок сохраняется в сеансе, но он комментирует (перефразируя здесь), что это неверная реализация интерфейса, так как вы не можете «отправить» сеанс коллеге, но вы можете отправить ресурс состояние, которое будет иметь все элементы в вашей корзине. Я нашел эту концепцию интересной, и мне было интересно, есть ли у кого-нибудь дополнительная информация, ресурсы, ссылки, видео и т. Д., Которые фактически обсуждают реализации архитектуры для такого рода вещей (предпочтительно в Java). Спасибо!

EDIT:

Извините, я собираюсь сделать небольшое редактирование здесь - я не говорю о желании получить информацию о реализации REST как таковой, но хочу о недостатках / преимуществах реального использования состояния ресурса по сравнению с состоянием сеанса / базы данных.

Answer 1

Одно из самых ясных объяснений недостатков состояния сеанса исходит непосредственно из диссертации Роя Филдинга , где он вводит REST. (Акцент мой)

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

Сессия Таким образом, состояние сохраняется полностью клиент.

Это ограничение индуцирует свойства видимости, надежности, и масштабируемость.

Видимость есть улучшена, потому что система мониторинга не должен смотреть за пределы одного запросить данные для определения полный характер запроса.

Надежность улучшена, потому что это облегчает задачу восстановления после частичные сбои [133].

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

Рой продолжает говорить, что применение этого ограничения является компромиссом при проектировании, и этот выбор имеет негативные последствия.

Как только вы решите не использовать состояние сеанса в архитектуре приложения, у вас останется поддержка таких вещей, как корзины покупок, одним из двух способов. Либо корзина полностью поддерживается клиентским приложением, либо сохраняется как состояние ресурса. Что делает ресурс ресурсом, так это то, что он идентифицируется URI и может управляться стандартными глаголами интерфейса. Если вы сохраняете корзину как Ресурс, то, как говорит Стефан, вы можете отправить ссылку на ресурс коллеге. При таком подходе корзина покупок может быть реализована так же, как и любой другой ресурс.

Answer 2

и мне было интересно, есть ли у кого-нибудь дополнительная информация, ресурсы, ссылки, видео и т. Д., Которые фактически обсуждают реализации архитектуры для такого рода вещей (предпочтительно в Java). Спасибо!

Кстати, "дружественный контроллер URL" будет достаточно. Создайте фильтр и / или сервлет, который извлекает HttpServletRequest#getRequestURI() или HttpServletRequest#getPathInfo(), создает некоторый javabean с данными REST, выполняет соответствующие действия с использованием шаблона команды и, наконец, перенаправляет на Страница JSP, о которой идет речь, для представления данных.

Имейте в виду, что длина URL-адресов ограничена определенными границами, которые зависят от используемого веб-браузера и веб-сервера. Я бы рекомендовал не делать это длиннее 255 символов. Если вам действительно нужно хранить больше информации в URL, рассмотрите возможность GZipping и Base64 кодирования и добавьте его в конец URL, что-то вроде http://example.com/cart/2j34hfg5jh2g5bnvcnb2vc452. Он не делает URL более читабельным, нет, но он работает и может передать много информации.