Действительно ли сеанс, хранящийся в базах данных, нарушает RESTfulness?
Я читал много статей, в которых говорилось, что сеансы нарушают безгражданство в отношении REST.
Если пользователь входит на сервер, сервер передает клиенту файл cookie сеанса (ssid) и сохраняет данные сеанса (данные пользователя) на сервере, в данном случае в памяти.
Логично, что это нарушает безгражданство.
Но как насчет хранения сеанса в базе данных?
Если пользователь входит на сервер, сервер передает клиенту файл cookie сеанса (ssid) и сохраняет данные сеанса в базе данных mysql, а не в памяти.
Это тоже нарушение безгражданства?
Если это так, то в чем разница между «хранением сеанса в базе данных» и «запросом пользователя, который делает запрос к данным базы данных?»
Оба они извлекают некоторые данные из базы данных при выполнении запроса клиента.
Очевидно, что последнее не нарушает безгражданства, иначе REST архитектура никогда не была бы такой популярной.
мой предыдущий вопрос, Нарушение RESTfulness в отношении базы данных, ответчик говорит, что «это не нарушает»
Наоборот, Действительно ли сеансы нарушают RESTfulness? ответчик говорит "да, это нарушение". но этот ответ может быть связан только с серверной стороной (памятью).
Так запутался.
Ответы 1
Отсутствие состояния в REST, в частности, относится для информативности сообщений.
Это означает, что каждый запрос должен содержать всю информацию, необходимую серверу для обработки сообщения. Запрос не может ссылаться на предыдущие запросы контекста. Связанный документ (диссертация Филдинга, происхождение REST) довольно подробно описывает Зачем, что ограничение полезно для распределенных систем.
Таким образом, в конце концов, не имеет значения, находится ли что-то в базе данных или в памяти на сервере, клиент не должен полагаться на ранее установленное состояние диалога для последующих запросов.
Подумайте об этом так: клиент может отложить свои следующие запросы на несколько дней, или клиент может выполнить запрос из какой-либо формы закладок, или запрос может отправиться на другой сервер, чем все предыдущие запросы. Или это может быть первый запрос, который делает клиент. Все это должно работать точно так же.
Еще один важный момент заключается в том, что «состояние сеанса» отличается от связанных с бизнесом вещей, хранящихся в базах данных (на которые вы, похоже, ссылаетесь). Конечно, сервер может хранить информацию, связанную с бизнесом, в своей базе данных, он может даже хранить или кэшировать (в памяти) данные входа в систему или состояние разговора, если он этого хочет, и все в порядке. Однако клиент и сервер могут нет «обогатить» запрос контекстом из предыдущих запросов.
Таким образом, клиент может запросить выполнение запроса к некоторой базе данных, которая, очевидно, имеет некоторое «состояние». Чего он может не делать, так это сказать: выполните этот запрос с дополнительными параметрами (такими как логин), указанными в каком-то предыдущем запросе, который я сделал.
Эта линия может размываться в некоторых случаях, например, когда сервер позволяет создавать «транзакции» для клиентов в качестве ресурсов. Но если вы сомневаетесь, всегда знайте Зачем, что вам нужно это свойство и какое значение вы хотите получить от него в вашей конкретной архитектуре.
Типичным примером является, конечно, информация для входа в систему, такая как имя пользователя, права или роли, определенные в запросе «входа», сделанном ранее. Но может включать в себя такие вещи, как: бизнес-объект, над которым вы «в настоящее время» работаете (текущий клиент, которого вы обслуживаете, и т. д.), последние выполненные запросы и т. д.
У меня еще один вопрос, если можно! Как насчет сеанса корзины покупок? когда клиент кладет товар в корзину, сервер сохраняет эту информацию как сеанс. Но, как вы сказали, похоже, что следующий запрос может не относиться к предыдущему контексту. Все, что хранит пользователь, не повлияет на следующий запрос. Так что это не нарушает безгражданство REST. Надеюсь я правильно понял!
Корзина покупок на сервере мог нарушает REST и безгражданство, если реализована таким образом. Однако обычно это состояние, связанное с бизнесом, поддерживаемое сервером, а не состояние связи между сервером и клиентом, что было бы нормально. Но, как я уже сказал, некоторые вещи сводятся к интерпретации. Теоретически вы также можете хранить корзину покупок на клиенте, что сделает дизайн менее двусмысленным. Оба работают, и оба совместимы с REST и безгражданством, если все сделано правильно.
"может нарушить" имеет смысл. Также было бы важно быть гибким, только чтобы не исправлять реализацию после REST. ценить это.
Хорошее объяснение! Можете ли вы привести пример «дополнения запроса контекстом из предыдущих запросов»? Я почти там.