Нарушают ли сеансы на стороне сервера REST?

По словам Роя Филдинга (одного из главных авторов спецификации HTTP) в своем оригинальном тезисе « Архитектурные стили» при обсуждении REST , он упоминает:

[E] любой запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать какой-либо сохраненный контекст на сервере.

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

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

Концепция сеанса является общей - в частности для веб-разработчиков - но является ли она RESTful в соответствии с приведенным выше определением?

Я бы сказал, да, состояние сеанса делает приложение RESTful не RESTful. Тривиальный пример, моя сестра подписывается на Wall Street Journal. На регулярной основе она будет что-то читать за платным экраном и решит отправить ссылку (через свой почтовый клиент, а не через WSJ) другу, у которого нет учетной записи WSJ. Нажмите, отправить, потерпеть неудачу. Очевидно, что опыт моей сестры по этому адресу отличается от опыта ее подруги.

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

Мое текущее решение состоит в том, чтобы хранить весь UI / ACL / любую информацию, необходимую для представления, в отдельном объекте и возвращать URL (вероятно, UUID) для этого объекта. Я считаю, что доступ к объекту представления можно считать RESTful в том смысле, что каждый, кто им владеет, получает одинаковую информацию / опыт.

Нарушают ли сеансы на стороне сервера REST?

Они определенно делают! При реализации REST не должно быть сеансов на стороне сервера, в противном случае у вас есть гибридное решение RPC / REST.

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

Вероятно, зависит от того, что вы подразумеваете под «данными сеанса». Это точный термин?

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

Я был бы очень удивлен, если бы такая операция была помечена как не RESTful. OAuth является примером.

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

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

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

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

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

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