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

14

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

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

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

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

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

Matt
источник
2
Я бы сказал, что в соответствии с этим определением практически нет ничего успокоительного, но насколько это определение достаточно логично? Представьте себе "спокойный" поиск в Google, где вы должны указать индекс Интернета в запросе к Google, чтобы он мог найти вас. Какая? Нет, говорить, что у вас не может быть хранилища постоянства и быть спокойным, было бы равносильно тому, что спокойные интерфейсы на самом деле бессмысленны. Это не значит, что мы все должны начать поддерживать сессии в памяти и говорить, что это все еще хороший дизайн отдыха ...
Джимми Хоффа
3
Я думаю , следует отметить , что есть различие между состоянием приложения и состояния ресурсов (индекс Google будет ресурсное состояние, и вполне законно). Я должен сделать это более ясным в вопросе.
Мэтт
есть такое различие? Пожалуйста, определите это. :) Я видел, как люди пытались определить их раньше, но это становится очень размытым, потому что они на самом деле не отличаются. Они оба являются изменяемыми данными, единственное существенное различие между одной формой состояния и другой заключается в том, является ли оно постоянным или нет, где не форма означает, что она обычно восстанавливаема, что и делает ее отличной.
Джимми Хоффа
1
Я задавался вопросом это сам. Поскольку никто никогда не объяснял, почему мое приложение должно хотеть золотую "спокойную" звезду, я не очень беспокоюсь об этом.
PSR

Ответы:

10

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

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

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

Питер Роуэлл
источник
1
Вы посмотрите на пример объекта, это другой угол в этом вопросе. Ухоженная.
Мэтт
Принимая это как ответ, несмотря на другие замечательные ответы, главным образом потому, что он отвечает на вопрос напрямую и дает очень четкий пример. Кроме того, вторая часть на объектах представления наклонила весы.
Мэтт
1
Если вы говорите, что сайт wsj является примером приложения без отдыха, я бы не согласился, что ваш пример показывает это. Если сайт WSJ, например, полагается на данные, предоставленные клиентом вашей сестры, для представления ей данных, то по определению @Matt, RESTful. Однако если он полагается на временное состояние сеанса в памяти, то, по определению Мэтта, он не является RESTful. Я просто указываю на это, потому что определение, данное Мэттом, основано на особенностях реализации, в то время как REST лучше определяется техникой потребления.
Джимми Хоффа
@JimmyHoffa - Мое понимание ограничений REST заключается в том, что он не имеет состояния . Это кажется довольно однозначным для меня.
Питер Роуэлл
Если бы у приложения WSJ не было состояния, клиент должен был отправить видимую статью. Эта статья может быть отредактирована администраторами сайта в любое время, не сомневайтесь, это часть состояния приложения WSJ. Я думаю , что нужно стремиться к различию в том, что это постоянное состояние, поэтому оно будет иметь больше гарантий и меньше накладных расходов на управление, чем непостоянное состояние, такое как сеансы, наряду с более простым контролем атомарности в транзакциях на нем. Это наряду с простой моделью потребления - то, для чего люди хотят отдохнуть. (Я думаю)
Джимми Хоффа
2

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

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

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

dasblinkenlight
источник
1

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

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

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

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

Кос
источник
1

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

Puckl
источник
это не обязательно верно, что пользователи увидят то же самое. Access может диктовать, сколько каждый пользователь увидит.
Эрик
@Erik Но пользователь должен указать, сколько он хочет видеть в запросе (включая использование заголовка Accept), поэтому ответы Puckl остаются в силе.
Йохан
1
@Johan Я бы вернул разные данные для разных пользователей с одной и той же конечной точки. Иначе какой смысл аутентифицировать пользователя.
Эрик
@ Эрик Я бы тоже так сделал. Тем не менее, я считаю, что аутентификация находится за пределами состояния ресурса, поэтому, строго говоря, если аутентифицированный пользователь влияет на представление, то он больше не RESTful. Возможно, если вам нужен значок RESTful, вам следует создать несколько «представлений» ресурса, в зависимости от того, кто запрашивает доступ, он разрешает доступ только к некоторым представлениям. Таким образом, public может получить доступ к / userprofiles / {userID} / publicview, а пользователь получит доступ к / userprofiles / {userID} / fullprofile, а авторизованные друзья получат доступ к / userprofiles / {userID} / friendsview
Йохан
0

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

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

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

Oleksi
источник
Я не согласен. У вас есть торговый сайт, который позволяет фильтровать по марке, цвету и размеру. Традиционные веб-сайты Web 1.0 справились бы с некоторыми флажками, сессией на стороне сервера и POST. Если я захочу поделиться ссылкой на example.org/shirts, люди не увидят, что я выбрал Medium, Black and Roots. (Это также приводит к появлению уродливого сообщения «Вы перезаписываете данные», когда вы нажимаете назад.) Но если я поделюсь ссылкой (например) на example.org/shirts/medium-black-roots, у всех будет одинаковое представление. Вся необходимая информация о состоянии находится в URL (или в теле POST, если это необходимо, но вы не можете поделиться этим).
Джесси Бьюкенен
... RESTful может не подходить для всего. Ориентирован ли ваш гипотетический ресурс на приложение (сайт для покупок, безусловно, есть!)? Возможно, это может не подходить для RIA с большим количеством государства, которое не ориентировано на ресурсы. Я не могу придумать ни одного хорошего примера, если честно.
Джесси Бьюкенен
0

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

eulerfx
источник