Ответ 1

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

На самом деле существует два вида государства. Состояние приложения, которое живет на клиенте, и состояние ресурса, которое живет на сервере.

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

Состояние ресурса одинаково для каждого клиента, и его правильное место на сервере. Когда вы загружаете изображение на сервер, вы создаете новый ресурс: новое изображение имеет свой собственный URI и может быть целью будущих запросов. Вы можете получить, изменить и удалить этот ресурс через HTTP.

Надеюсь, что это помогает дифференцировать то, что означает безгражданство и различные состояния.

Ответ 2

Основное объяснение:

Нет состояния сеанса клиента на сервере.

Без сохранения состояния это означает, что сервер не хранит никакого состояния о сеансе клиента на стороне сервера.

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

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

Состояние приложения клиента никогда не должно храниться на сервере, а должно передаваться от клиента во все места, где это необходимо.

Вот откуда происходит ST в REST, State Transfer. Вы передаете состояние вместо того, чтобы сервер сохранял его. Это единственный способ масштабирования до миллионов одновременно работающих пользователей. Если ни по какой другой причине, кроме как потому, что миллионы сеансов - это миллионы сеансов.

Нагрузка на управление сеансом амортизируется для всех клиентов, клиенты сохраняют свое состояние сеанса, и серверы могут обслуживать многие заказы или более клиентов без сохранения состояния.

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

Stateless - это то, как протокол HTTP и сеть в целом были спроектированы для работы, и это в целом более простая реализация, и у вас есть один путь кода вместо набора логики на стороне сервера для поддержки группы состояния сеанса.

Есть несколько очень простых принципов реализации:

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

Таким образом, пять ключевых принципов:

1. Дайте каждой "вещи" удостоверение личности
2. Связать вещи вместе
3. Используйте стандартные методы
4. Ресурсы с несколькими представлениями
5. Общаться без гражданства

Нет ничего об аутентификации или авторизации в диссертации REST.

Потому что ничто не отличается от аутентификации запроса, который является RESTful, от запроса, который не является. Аутентификация не имеет отношения к обсуждению RESTful.

Объяснять, как создать приложение без сохранения состояния для ваших конкретных требований, слишком сложно для StackOverflow.

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

Комментарии с просьбой о помощи/информации по этому желанию/должны быть помечены как "Больше не нужны".

Ответ 3

Они просто говорят, что не используют хранилище данных уровня сеанса/приложения?

Нет. Они не говорят об этом тривиальным образом.

Они говорят, что не определяют "сеанс". Не входите в систему. Не выходить из системы. Предоставьте учетные данные с запросом. Каждый запрос стоит один.

У вас все еще есть хранилища данных. У вас все еще есть аутентификация и авторизация. Вы просто не тратите время на создание сеансов и сохранение состояния сеанса.

Дело в том, что каждый запрос (а) стоит полностью один и (б) может быть тривиально обработан в гигантскую параллельную ферму серверов без какой-либо реальной работы. Apache или Squid могут передавать запросы RESTful вслепую и успешно.

Что делать, если у меня была очередь сообщений, и мой пользователь хотел прочитать сообщения, но, читая их, хотел заблокировать некоторые сообщения отправителей, проходящие в течение всего сеанса?

Если пользователю нужен фильтр, просто укажите фильтр для каждого запроса.

Разве не имеет смысла... отправлять сервер только сообщения (или идентификаторы сообщений), которые не были заблокированы пользователем?

Да. Предоставьте фильтр в запросе URI RESTful.

Нужно ли мне отправлять весь список отправителей сообщений каждый раз, когда я запрашиваю новый список сообщений?

Да. Насколько велик этот "список отправителей сообщений"? Краткий список ПК?

Запрос GET может быть очень большим. При необходимости вы можете попробовать запрос POST, даже если это похоже на какой-то запрос.

Ответ 4

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

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

Это компромисс.

Ответ 5

Историческое представление состояния управления пользовательскими приложениями

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

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

HTML5 и XML Header Request со временем стандартизировали понятие хранения сложных данных, включая состояние приложения стандартным образом на стороне клиента (то есть браузера), не прибегая к переходу между сервером.

Общее использование служб REST

Службы REST обычно вызывается, когда есть транзакция, которая должна быть выполнена, или если требуется получить данные.

Службы REST предназначены для вызова клиентским приложением, а не для конечного пользователя.

Аутентификация

Для любого запроса на сервер часть запроса должна содержать токен авторизации. Как это реализовано, зависит от приложения, но в целом это либо форма проверки подлинности BASIC, либо CERTIFICATE.

Аутентификация на основе форм не используется службами REST. Однако, как отмечено выше, службы REST не предназначены для вызова пользователем, а приложением. Приложение должно управлять получением токена аутентификации. В моем случае я использовал файлы cookie с JASPIC с OAuth 2.0 для подключения к Google для аутентификации и простой проверки подлинности HTTP для автоматического тестирования. Я также использовал HTTP-заголовковую аутентификацию через JASPIC для локального тестирования (хотя такой же подход может быть выполнен в SiteMinder)

В соответствии с этими примерами аутентификация управляется на стороне клиента (хотя SiteMinder или Google будут хранить сеанс аутентификации на своем конце), ничего не может быть сделано об этом состоянии, но это не является частью службы REST приложение.

Запросы на поиск

Запросами на поиск в REST являются операции GET, где запрашивается конкретный ресурс и кэшируется. Нет необходимости в сеансах сервера, потому что у запроса есть все необходимое для извлечения данных: аутентификация и URI.

Сценарии транзакций

Как отмечалось выше, клиентское приложение само по себе вызывает службы REST вместе с аутентификацией, которую он управляет также на стороне клиента.

Что это означает, что для служб REST [если сделано правильно] требуется один запрос на сервер REST, будет содержать все, что необходимо для одной пользовательской операции, которая делает все, что требуется в одной транзакции, a Транзакция Script - это то, что называется шаблоном.

Это обычно выполняется с помощью запроса POST, но также могут использоваться другие, такие как PUT.

Множество надуманных примеров REST (я сам это сделал) пытался следовать за тем, что было определено в протоколе HTTP, после прохождения этого я решил быть более прагматичным и оставил его Только GET и POST. Метод POST даже не должен реализовывать шаблон POST-REDIRECT-GET.

Несмотря на это, как я уже отмечал выше, клиентское приложение будет тем, кто вызывает эту услугу, и он будет вызывать только запрос POST со всеми данными, когда это необходимо (не каждый раз). Это предотвращает постоянные запросы на сервер.

опрос

Хотя REST также может использоваться для опроса, я не буду рекомендовать его, если вы не будете использовать его из-за совместимости с браузером. Для этого я бы использовал WebSockets, который я разработал

Ответ 6

REST очень абстрактно. Это помогает иметь некоторые хорошие, простые, реальные примеры.

Возьмем, к примеру, все основные приложения для социальных сетей - Tumblr, Instagram, Facebook и Twitter. У всех их есть прокручиваемый вид, где дальше вы прокручиваете вниз, чем больше контента вы видите, тем дальше и дальше назад. Тем не менее, мы все испытали тот момент, когда вы потеряли место, где вы были прокручены, и приложение сбрасывает вас обратно. Например, если вы покинете приложение, то, когда вы его снова откроете, вы снова вернетесь наверх.

Причина в том, что сервер не сохранил ваше состояние сеанса. К сожалению, ваша позиция прокрутки была просто сохранена в ОЗУ на клиенте.

К счастью, вам не нужно входить в систему при повторном подключении, но это только потому, что ваш клиентский сертификат также не сохранил регистрационный сертификат. Удалите и переустановите приложение, и вам придется заходить в систему, потому что сервер не связывал ваш IP-адрес с вашим сеансом.

У вас нет сеанса входа на сервер, потому что они соблюдают REST.

Теперь приведенные выше примеры не связаны с веб-браузером вообще, но на заднем плане приложения обмениваются данными через HTTPS с их хост-серверами. Я хочу сказать, что REST не должен включать файлы cookie и браузеры и т.д. Существуют различные способы хранения состояния сеанса на стороне клиента.

Но давайте поговорим о веб-браузерах на секунду, потому что это вызывает еще одно важное преимущество REST, о котором здесь никто не говорит.

Если сервер попытался сохранить состояние сеанса, как он должен идентифицировать каждого отдельного клиента?

Он не мог использовать свой IP-адрес, потому что многие люди могли использовать тот же адрес на общем маршрутизаторе. Итак, как же тогда?

Он не может использовать MAC-адрес по многим причинам, не в последнюю очередь из-за того, что вы можете войти в несколько разных учетных записей Facebook одновременно в разных браузерах и в приложении. Один браузер может легко притворяться другим, а MAC-адреса так же легко обманывать.

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

Итак... Я надеюсь, что теперь вы видите, почему REST так важен для масштабируемости. Надеюсь, вы можете начать понимать, почему серверное состояние сеанса - это масштабируемость сервера, что сварочные наковальни для ускорения автомобиля.

Когда люди путаются, думая, что "состояние" относится, например, к информации, хранящейся в базе данных. Нет, это относится к любой информации, которая должна находиться в ОЗУ сервера, когда вы его используете.

Ответ 7

Я вижу, что основная проблема здесь заключается в смешивании Session с State. И хотя REST указывает, что вы НЕ должны хранить состояние на сервере, ничто не мешает вам хранить сеанс пользователя.

Управление Состояние на сервере означает, что ваш сервер точно знает, что делает клиент (какую страницу они просматривают в каком разделе приложения). И это то, что вам не нужно делать.

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

Кто-то может утверждать, что клиент должен лучше генерировать токен. Я говорю, что это работает в обоих направлениях, и это будет зависеть от приложения, и кто будет работать с API.

Также необходимо правильно определить некоторые конфиденциальные данные сеанса на сервере. Вы не можете доверять клиенту, чтобы сохранить свою корзину покупок, например (например), в поле "isFreeGift". Такая информация должна храниться на сервере.

Видеосвязь, предоставленная Сантану Дей в его ответе, полезна. Наблюдайте за этим, если вы этого не сделали.

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

Althoght вопрос несколько лет, я надеюсь, что мой ответ будет по-прежнему полезен.

Ответ 8

Безстоящий означает, что состояние службы не сохраняется между последующими запросами и ответом. Каждый запрос имеет свои собственные учетные данные пользователя и индивидуально аутентифицирован. Но в stateful каждый запрос известен из любого предыдущего запроса. Все запросы с учетом состояния ориентированы на сеанс, то есть каждый запрос должен знать и сохранять изменения, сделанные в предыдущих запросах.

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

Да, протокол http - это, по сути, протокол без сохранения состояния, но чтобы сделать его с сохранением состояния, мы создаем файлы cookie HTTP. Таким образом, SOAP по умолчанию. Но это может быть сделано также с учетом состояния, зависит от используемой структуры.

HTTP является апатридом, но все же мы можем поддерживать сеанс в нашем Java-приложении, используя другой механизм отслеживания сеанса.

Да, мы также можем поддерживать сеанс в webservice независимо от того, является ли он REST или SOAP. Он может быть реализован с использованием любой сторонней библиотеки или вы можете реализовать самостоятельно.

Взято из http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

Ответ 9

Посмотрите на эту презентацию.

http://youtu.be/MRxTP-rQ-S8

Согласно этому шаблону - создайте временные спокойные ресурсы для управления состоянием, если и когда это действительно необходимо. Избегайте явных сессий.

Ответ 10

Там нет ложки.

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

Слово в логине каждый раз, когда дебаты

Что вообще значит не вести сеанс и входить каждый раз? Некоторые означают "отправлять пароль каждый раз", это просто глупо. Некоторые говорят: "Нет, конечно, нет, вместо этого отправьте токен" - и вот, PHP-сессия делает это почти точно. Он отправляет идентификатор сеанса, который является своего рода токеном, и помогает вам получить доступ к вашим личным материалам без повторной отправки u/pw каждый раз. Это также довольно надежно и хорошо проверено. И да, удобно, что может превратиться в недостаток, см. следующий абзац.

Уменьшить след

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

Общее хранилище является обязательным. Сервер должен знать, по крайней мере, кто-то вошел в систему или нет. (И если вы беспокоитесь о базе данных каждый раз, когда вам нужно решить это, вы практически обречены.) Общие хранилища должны быть намного быстрее, чем база данных. Это приносит соблазн: хорошо, у меня очень быстрое хранилище, почему бы не сделать все там? - и там, где все идет не так, как надо.

То есть вы говорите, что хранилище сеансов должно быть минимальным?

Опять же, это ваше решение. Вы можете хранить вещи там из соображений производительности (база данных почти всегда медленнее, чем Redis), вы можете хранить информацию избыточно, реализовывать собственное кэширование, что угодно - просто имейте в виду, что веб-серверы будут иметь большую нагрузку, если вы будете хранить много мусора на них. Кроме того, если они сломаются под большими нагрузками (и они будут), вы потеряете ценную информацию; При REST-мышлении в этом случае все, что происходит, - это когда клиент снова отправляет тот же (!) запрос, и на этот раз он обслуживается.

Как это сделать правильно?

Здесь нет универсального решения. Я бы сказал, выбрать уровень безгражданства и пойти с этим. Одни сеансы могут быть любимыми и ненавистными для других, но они никуда не денутся. С каждым запросом отправляйте столько информации, сколько имеет смысл, чуть больше, возможно; но не интерпретируйте безгражданство как отсутствие сеанса или вход в систему каждый раз. Каким-то образом сервер должен знать это вам; Идентификаторы сеансов PHP - это хороший способ, а токены, созданные вручную, - другой.

Думайте и решайте, не позволяйте тенденциям дизайна думать за вас.

Ответ 11

Основное различие между stateeless vs Stateful - это передача данных на сервер каждый раз. В случае отсутствия состояния клиент должен предоставить всю информацию, поэтому в каждом запросе может потребоваться множество параметров. В Stateful клит передает эти параметры один раз, и они поддерживаются сервером до тех пор, пока клиент не изменяет его.

IMO, API должен быть апатридом, который дает возможность быстро масштабироваться.

Ответ 12

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

Этот REST ограничение безгражданства очень важен. Без применения этого ограничения ваше приложение на стороне сервера не будет scale, так как сохранение каждого отдельного сеанса клиента будет ахиллесова пята.

Ответ 13

Вся концепция различна... Вам не нужно управлять сеансами, если вы пытаетесь реализовать протокол RESTFul. В этом случае лучше выполнять процедуру аутентификации по каждому запросу (тогда как для нее есть дополнительные затраты с точки зрения производительности - хеширование пароля было бы хорошим примером, а не большой проблемой...). Если вы используете сеансы - как вы можете распределять нагрузку на несколько серверов? Уверен, что протокол RESTFul предназначен для устранения сеансов вообще - вам они действительно не нужны... Поэтому его называют "без гражданства". Сеансы требуются только в том случае, если вы не можете хранить что-либо, кроме Cookie, на стороне клиента после того, как был сделан запрос (например, возьмите старый браузер, не поддерживающий Javascript/HTML5). В случае "полнофункционального" клиента RESTFul обычно безопасно хранить base64(login:password) на стороне клиента (в памяти) до тех пор, пока приложение не будет загружено - приложение используется для доступа к единственному узлу, и cookie не может быть скомпрометирован по сторонним скриптам...

Я бы настоятельно рекомендовал отключить аутентификацию cookie для служб RESTFul... проверить Basic/Digest Auth - этого должно быть достаточно для служб на основе RESTFul.

Ответ 14

REST не имеет состояния и не поддерживает состояния между запросами. Клиентские куки/заголовки настроены на поддержание пользовательского состояния, такого как аутентификация. Скажем, имя пользователя/пароль клиента проверяются механизмом аутентификации третьей стороны - получение OTP 2-го уровня и т.д. Как только пользователь проходит аутентификацию - заголовки/файлы cookie доходят до конечной точки службы покоя, и мы можем считать пользователя аутентифицированным, поскольку пользователь приходит с действительными заголовками/файлами cookie., Теперь определенная информация о пользователе, например IP, либо сохраняется в кэше, и после этого, если запрос поступает с того же Ip (mac-адреса) для перечисленных ресурсов, пользователю разрешено. И кеш поддерживается некоторое время, которое становится недействительным по прошествии времени. Таким образом, можно использовать либо кэш, либо записи БД для сохранения информации в ч/б запросах.

Ответ 15

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

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

Это может поддерживать или отслеживать состояние пользователя в приложении.

Надеюсь это поможет!

Ответ 16

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

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

Если RESTful API ожидает имя пользователя и пароль для изменения имени пользователя и пароля, то даже если кто-то выдал себя за пользователя с помощью идентификатора сеанса, хакер не сможет заблокировать реального пользователя.

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

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