Можно сессию и в памяти хранить, если обеспечить, чтобы данные не удалялись при недостатке памяти. Но сам факт переноса сессии с диска или БД, например, в память, говорит о том, что с хранением её на диске или БД возникли сложности. Таким образом можно любые часто используемые данные, с которыми у нас проблемы, перенести в память.
В самой сессии ничего плохого нет. Плохо, когда в ней хранят совсем не подходящие для неё данные. Я видел реализации, когда помещали в сессию десятки мегабайт данных на каждого пользователя и обновляли их при каждом запросе, что вызывало при значительном количестве пользователей проблемы.
Если есть необходимость оптимизировать по количеству запросов, то для пользовательских данных гипотетически можно использовать один композитный ресурс и забрать их одним GET-запросом.
Заместо одного GET-запроса — два. Причем один из них с большой вероятностью берется из кэша, а второй в идеальном случае может не выполняться, если нет необходимости забирать с сервера пользовательские данные. От сессий отказываться не обязательно.
Хранение пользовательских данных на сервере не нарушает принципов REST. Нарушает принципы REST хранение состояния клиента. Надо смотреть конкретные примеры, конкретные приложения, конкретные данные, чтобы разговор был предметный.
Ввести клиентский кэш — не самоцель. Во многих случаях публичный клиентский кэш вообще нельзя использовать по соображениям безопасности.
Семантика конкретных данных в приложении зависит от этого самого конкретного приложения. Если пользователь мигрировал на другой клиент и есть необходимость вместе с миграцией перенести данные, то эти данные — пользовательские и их надо хранить на сервере.
Смысл в том, чтобы не хранить на сервере состояние клиента, как субъекта отношений клиент-сервер.
Данные конкретного пользователя, который подключается через разные клиенты, хранить надо. Но что считать пользовательскими данными, а что считать состоянием клиента, решает разработчик приложения.
1: PUT (известна дата изменения — именуем D1, возвращает ETag — именуем E1)
2: PUT (может, конечно, отправить запрос без предварительных условий, но это не правильно)
1: PUT (задаем два условия: If-Match: E1, If-Unmodified-Since: D1)
Надо разделять понятия: хранить состояние клиента (как субъекта отношений клиент-север) и хранить пользовательские данные. Например, флаг «держать меню свернутым» — это скорее состояние клиента, о нем вообще сервер не должен ничего знать, а тем более хранить у себя. Но список заказов конкретного пользователя — это пользовательские данные. И их, конечно, надо показывать авторизованному пользователю, если он их хозяин. Факт авторизации, конечно, можно хранить в сессии. Но если прорисовываем нейтральную по отношению к пользователю информацию (например, страницу товара), почему основной контент страницы не сделать свободным от состояния клиента и, возможно, от сессий вообще, особенно, если большинство пользователей этой страницы — не авторизованные.
Целью статьи не было все свести к REST, здесь изложена классификация HTTP-методов в плане безопасности и идемпотентности, а так же сделан акцент на совместимости и компоновке веб-приложения, которая облегчила бы прозрачное кэширование значительной части контента на клиенте и промежуточными узлами. Понятно, что окружающий мир многообразен, и редко какая методология, архитектура или модель охватывает все его нюансы.
REST вполне неплохо работает и с композитными ресурсами, и с вычислениями, и с асинхронными задачами. Выкручивать руки себе не надо, согласен, надо брать лучшее и осмысленно это использовать.
Страницу можно собрать на сервере, не включая туда данные, зависящие от состояния текущего клиента. Если необходимо отрисовать элементы, зависящие от состояния клиента, то клиент или берет их из своего хранилища, или запрашивает на сервере.
В самой сессии ничего плохого нет. Плохо, когда в ней хранят совсем не подходящие для неё данные. Я видел реализации, когда помещали в сессию десятки мегабайт данных на каждого пользователя и обновляли их при каждом запросе, что вызывало при значительном количестве пользователей проблемы.
Ввести клиентский кэш — не самоцель. Во многих случаях публичный клиентский кэш вообще нельзя использовать по соображениям безопасности.
Смысл в том, чтобы не хранить на сервере состояние клиента, как субъекта отношений клиент-сервер.
Данные конкретного пользователя, который подключается через разные клиенты, хранить надо. Но что считать пользовательскими данными, а что считать состоянием клиента, решает разработчик приложения.
2: PUT (может, конечно, отправить запрос без предварительных условий, но это не правильно)
1: PUT (задаем два условия: If-Match: E1, If-Unmodified-Since: D1)
REST вполне неплохо работает и с композитными ресурсами, и с вычислениями, и с асинхронными задачами. Выкручивать руки себе не надо, согласен, надо брать лучшее и осмысленно это использовать.