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

В ООП временные данные - это состояние объектов, которые получают на вход данных из источников долговременного хранения, и до момента выдачи результата сохраняют свое состоение. В ФП программирование временные данные - это состояние переменных, которые используются внутри функции.

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

Стандартный запрос

Схемы хранения состояния сеанса:

Варианты клиентов:

Форматы данных:

Для корректной работы следует сразу предусмотреть версионирование.

Версионирование

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

Основные характеристики:

Достоинства:

Недостатки:

Серверное хранилище

Проблема законченных и потерянных сеансов

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

Хранить срок истечения для каждого сенаса не обязательно, вместо этого можно создать таблицу (или директорию, в случае файловго хранения сеанса) с ограниченным сроком жизни, по истечении срока жизни таблица она полностью удаляется. Имя таблицы в таком случае строится по регулярному выражению.

Сериализация

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

- Частичная сериализация состояния объекта;
- Полная сериализация объекта.

Частичная сериализация состояния объекта

Подход при котором программист сам решает какие данные должны быть сериализованны, для этого есть два варианта:

    - объект сам реализует методы сериализации (по сути это реализация 
    сохранения и восстановления стейта объекта), данный подход нарушает
    SOLID поэтому используется редко
    - сериализация публичного состояния объекта (обычно сериализуется 
    начальное состояние объекта, а при восстановлении состояния объект
    должен повторно выполнить все расчеты)

Преимущества:

Недостатки:

Полная сериализация объекта

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

Достоинства:

- простота

Недостатки:

- большой объем данных;
- низкий контроль;
- сложно делать сериализацию иерархии объектов.

Сериализованный крупный объект

Для сериализации сложных иерархий объектов можно сериализовать не каждый отдельный объект по отдельности, а сливать объекты в один большой объект и делать сериализацию данного объекта. Полученный результат хранить в БД.

Важно! Для корректного восстановления объектов нужно контролировать 
структуры сохраняемых данных с помощью версионирования.

Структура таблица БД может состоять из двух полей: идентификатор сессии и сериализованные данные, допускается дублирование данных для разных идентификаторов сессий.

Хранение состояния сеанса на сервере влечет сложности, связанные с масштабированием и развитием системы при большом количестве пользователей, а так же при сравнительно большом объеме хранения данных. Операции сериализации/десериализации довольно медленные, поэтому появились решения, сохраняющие состояние сессии на стороне клиента.

Примечание.
Клиент-серверные приложения работающие через Интернет
все чаще стали называть "веб-приложениями", более корректно
было бы называть веб-приложениями, только ту часть приложений,
которые работают через браузер (тонкий клиент).
Я буду использовать термин "веб-приложение" в более общем современном смысле.

Достоинства:

Недостатки:

Основной проблемой является проблема безопасности.

Примечание.
Для решения вопросов безопасности используется шифрование,
хэширование, цифровые подписи.

Варианты реализации

Существует несколько способов хранить состояние на клиенте, в зависимости от клиента варианты хранения сильно различаются.

Стандартный запрос

Толстый клиент

- собственные структуры
- DTO
- Models

Тонкий клиент

SPA (динамические):

- URL (около 4 тыс. знаков)
- Local Storage
- JavaScript объекты

HTML (статические):

- URL (около 4 тыс. знаков)
- Cookie
- Формы (скрытые поля)

В случае когда объем передаваемых данных слишком большой, хранить стейт только на клиенте или только на сервере не целесообразно. Чтобы иметь возможность оперативно выполнять обработку данных, а так же чтобы сохранить возможность масштабирования используют смешанную схему работы. Как правило при такой схеме клиент хранит порцию оперативной информации, а полный набор данных "размазывается" по серверам.

В данной схеме как правило используются разные схемы распределения нагрузки между серверами. И уходят от монолитной архитектуры серверной части.

Достоинства:

Недостатки:

Стандартный запрос смешанное хранение

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