Если REST-приложения должны быть без сохранения состояния, как вы управляете сессиями?
Я использую iReport 3.7.5 с *jasperserver 3.7.1* без проблем с сентября 2010 года. Но теперь я столкнулся с «неизвестной целью гиперссылки 0».
Я понял, что разница в том, что я делал до сих пор, - это другие отчеты, которые отлично работали, были отредактированы с использованием плагина iReport, а этот проблемный просто загружен через плагин iReport. Поэтому я попытался открыть блок отчетов jasperserver через плагин iReport, сделал небольшое редактирование и заменил блок отчета на этот файл. Тогда это сработало.
4 ответа
Отсутствие состояния означает, что каждый HTTP-запрос выполняется в полной изоляции. Когда клиент делает HTTP-запрос, он включает всю информацию, необходимую серверу для выполнения этого запроса. Сервер никогда не полагается на информацию из предыдущих запросов. Если эта информация важна, клиенту придется отправить ее еще раз в следующем запросе. Безгражданство также приносит новые возможности. Распределить приложение без отслеживания состояния по серверам с балансировкой нагрузки проще. Приложение без сохранения состояния также легко кэшировать.
На самом деле существует два типа состояний. Состояние приложения, которое живет на клиенте, и Состояние ресурса, которое живет на сервере.
Веб-сервис должен заботиться о состоянии вашего приложения только тогда, когда вы фактически делаете запрос. В остальное время он даже не подозревает, что вы существуете. Это означает, что всякий раз, когда клиент делает запрос, он должен включать все состояния приложения, которые потребуются серверу для его обработки.
Состояние ресурса одинаково для каждого клиента, и его надлежащее место находится на сервере. Когда вы загружаете изображение на сервер, вы создаете новый ресурс: новое изображение имеет собственный URI и может быть целью будущих запросов. Вы можете получать, изменять и удалять этот ресурс через HTTP.
Надеюсь, это поможет различить, что означают безгражданство и различные состояния.
Вы абсолютно правы, поддержка взаимодействия с сервером без сохранения состояния создает дополнительную нагрузку на клиента. Однако, если вы подумаете о масштабировании приложения, вычислительная мощность клиентов прямо пропорциональна количеству клиентов. Поэтому масштабирование на большое количество клиентов гораздо более осуществимо.
Как только вы возлагаете на сервер небольшую ответственность за управление некоторой информацией, связанной с взаимодействиями конкретного клиента, эта нагрузка может быстро возрасти и потреблять сервер.
Это компромисс.
Они просто говорят не использовать хранилище данных на уровне сеанса / приложения ???
Нет. Они не говорят об этом банально.
Они говорят, что не надо определять «сеанс». Не авторизуйтесь. Не выходите из системы. Укажите учетные данные с запросом. Каждый запрос стоит отдельно.
У вас все еще есть хранилища данных. У вас все еще есть аутентификация и авторизация. Вы просто не тратите время на создание сеансов и поддержание состояния сеанса.
Дело в том, что каждый запрос (а) полностью автономен и (б) может быть тривиально передан на ферму гигантских параллельных серверов без какой-либо реальной работы. Apache или Squid могут передавать запросы RESTful вслепую и успешно.
Что, если бы у меня была очередь сообщений, и мой пользователь хотел прочитать сообщения, но по мере их чтения хотел заблокировать приходящие сообщения определенных отправителей на время его сеанса?
Если пользователь хочет filter, а затем просто укажите фильтр для каждого запроса.
Разве не имеет смысла ... разрешить серверу отправлять только сообщения (или идентификаторы сообщений), которые не были заблокированы пользователем?
Да. Укажите фильтр в запросе RESTful URI.
Мне действительно нужно отправлять весь список отправителей сообщений для блокировки каждый раз, когда я запрашиваю новый список сообщений?
Да. Насколько большим может быть этот «список отправителей сообщений для блокировки»? Краткий список ПК?
Запрос GET может быть очень большим. При необходимости вы можете попробовать выполнить POST-запрос, даже если он звучит как своего рода запрос.
Фундаментальное объяснение таково:
На сервере нет состояния клиентской сессии.
Под stateless подразумевается, что сервер не хранит никакого состояния о клиентской сессии на стороне сервера.
Состояние клиентской сессии хранится на клиенте. Сервер без статических данных означает, что каждый сервер может обслуживать любого клиента в любое время, не существует сродства сессий или липких сессий. Соответствующая информация о сессии хранится на клиенте и передается на сервер по мере необходимости.
Это не мешает другим службам, с которыми общается веб-сервер, хранить информацию о бизнес-объектах, таких как корзины, только не о текущем состоянии приложения/сеанса клиента.
Состояние приложения клиента никогда не должно храниться на сервере, а передаваться от клиента во все места, где оно необходимо.
Вот откуда ST в REST - передача состояния. Вы передаете состояние вместо того, чтобы сервер хранил его. Это единственный способ масштабирования до миллионов одновременных пользователей. Если не по другой причине, то потому что миллионы сессий - это миллионы сессий.
Нагрузка по управлению сеансами амортизируется на всех клиентов, клиенты хранят состояние своих сеансов, а серверы могут обслуживать на много порядков больше клиентов в режиме stateless.
Даже для сервиса, который, по вашему мнению, будет требовать только 10 тысяч одновременных пользователей, вы все равно должны сделать свой сервис без статического состояния. Десятки тысяч - это все равно десятки тысяч, и с этим будут связаны временные и пространственные затраты.
Stateless - это то, как протокол HTTP и веб в целом были разработаны для работы, и это в целом более простая реализация, и у вас есть один путь кода вместо кучи логики на стороне сервера для поддержания состояния сессии.
Есть несколько основных принципов реализации:
Это принципы, а не реализация, и то, как вы будете выполнять эти принципы, может варьироваться.
В общем, пять ключевых принципов:
- Дайте каждой "вещи" идентификатор
- Свяжите вещи вместе
- Используйте стандартные методы
- Ресурсы с несколькими представлениями
- Общайтесь без статического состояния
В REST диссертации нет ничего об аутентификации или авторизации.
Потому что аутентификация запроса, который является RESTful, ничем не отличается от запроса, который таковым не является. Аутентификация не имеет отношения к обсуждению RESTful.
Объяснение того, как создать приложение без статических данных для ваших конкретных требований, является слишком широким для StackOverflow.
Реализация аутентификации и авторизации применительно к REST еще более слишком широка, а различные подходы к реализации очень подробно описаны в Интернете в целом.
Комментарии с просьбой о помощи/информации по этому поводу будут/должны быть просто помечены как. No Longer Needered.