Если REST-приложения должны быть без сохранения состояния, как вы управляете сессиями?

Question

Мне нужны некоторые разъяснения.Я читал о REST и создании приложений RESTful.Согласно википедии, сам REST определен как Представительный государственный перевод .Поэтому я не понимаю всех этих gobbledeygook , которые все продолжают извергать.

Из википедии:

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

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

Я понял, что одна из целей REST - сделать доступ к URI согласованным и доступным, например, вместо того, чтобы скрывать запросы подкачки внутри постов, делая номер страницы запроса частью GET URI.Имеет смысл для меня.Но кажется, что это просто выходит за рамки, говоря, что нет на данные клиента (данные сеанса) должны когда-либо храниться на стороне сервера.

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

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

Опять же, просто пытаюсь понять это.Кто-то уточните .

---

Обновление:

Я нашел вопрос о переполнении стека, ответ на который не совсем помог мне: Какуправлять состоянием в REST , что говорит о том, что важное состояние клиента должно передаваться всем при каждом запросе .... Ugg .. похоже на большие издержки ... Это правильно?

Answer 1

Ложки нет.

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

Слово о входе в систему каждый раз Дебаты

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

Сокращение площади

То, что вы должны сделать , вместо этого, и что имеет реальный смысл, так этоуменьшите ваш веб-сервер до минимума.Такие языки, как PHP, очень просто помещают все в хранилище сессий;Вы можете сделать это, но если у вас много веб-серверов, они должны использовать что-то общее между ними (NFS, Redis, Memcached, что-то), чтобы ваш следующий запрос знал, что вы сделали одним кликом ранее.Это связано с балансировкой нагрузки - вы можете оказаться на другом веб-сервере со своим следующим запросом.И хотя между ними ОБЯЗАТЕЛЬНО должно быть общее хранилище (в основном потому, что им придется определять, вошли вы в систему или нет), вы не должны использовать его в качестве альтернативной базы данных.Это не для этого.

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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