Действительно ли сеанс, хранящийся в базах данных, нарушает RESTfulness?

Question

Я прочитал много статей о том, что сеансы нарушают безгражданство в отношении REST.

Если пользователь входит на сервер, сервер передает cookie сеанса (ssid) клиенту и сохраняет данные сеанса (пользовательские данные) на сервере, в данном случае это память.

Имеет смысл, что это нарушает безгражданство.

Но как насчет хранения сеансов в базе данных?

Если пользователь входит в системусервер, сервер передает cookie сеанса (ssid) клиенту и сохраняет данные сеанса в базе данных mysql, а не в памяти.

Это также нарушает отсутствие состояния?

Еслиправда, в чем разница между «хранением сеанса в базе данных» и «запросом пользователя, который выполняет запрос к данным базы данных?»

Оба они извлекают некоторые данные из базы данных, когда запрос клиентаmade.

Очевидно, что последнее не нарушает безгражданства, иначе REST архитектура никогда не была бы такой популярной.

мой предыдущийНаш вопрос, Нарушение RESTfulness в отношении базы данных Ответчик говорит: "Это не нарушение"

И наоборот, Действительно ли сессии нарушают RESTfulness? Ответчик говорит: "Даэто нарушает ".но этот ответ может быть привязан только к серверной части (памяти).

Так запутано.

Answer 1

Безгражданство в REST, в частности относится к информативности сообщений.

Это означает, что каждый запрос должен содержать всю информацию, необходимую серверу для обработки сообщения. Запрос не может ссылаться на предыдущие запросы для контекста. В связанном документе (диссертация Филдинга, происхождение REST) ​​достаточно подробно описывается почему это ограничение полезно для распределенных систем.

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

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

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

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

Эта строка может размыться в некоторых случаях, например, когда сервер позволяет создавать «транзакции» для клиентов в качестве ресурсов. Но если вы сомневаетесь, всегда знаете , почему вам нужно это свойство и какое значение вы хотите получить от него в вашей конкретной архитектуре.