Насколько известно, REST не хранит состояние клиента между запросам.
Представьте что есть двухмерный лабиринт и есть робот, которому через REST отдают команды по перемещению по данному лабиринту. Надо довести робота из точки А в точку Б. В рамках нашей реализации это выглядит как-то так:
1. клиент отсылает путь, который робот должен пройти
2. сервер отвечает клиенту, достиг ли робот цели
3. клиент посылает команду взаимодействия с целью
3ий пункт имеет смысл только при успехе 2ого.
Конечно, никакого робота и лабиринта нет, это просто пример для демонстрации моей проблематики - каким-то образом надо логически объединить несколько запросов, что бы они считались одним целым, поскольку последующие не имеют смысла без предыдущих, что бы хранился некий контекст (в данном случае лабиринт и расположение робота) между запросами, и что бы всё это не нарушало REST
REST API не должен ничего хранить, это просто интерфейс взаимодействия двух хостов, клиента и сервера. Все данные обрабатываются и хранятся на конечных устройствах.
Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере. Сервер отсылает результаты изменений. После чего клиент должен совершить с ними преобразование и совершить снова запрос. Из-за необходимости совершения преобразования клиентом, взаимодействие выглядит не как "клиент отправил запрос - получил ответ и все довольны", а как "клиент отправил запрос, получил ответ, снова послал запрос, ну и очевидно опять получил ответ что бы узнать о результатах". Если бы клиент располагал всеми данными, то мог бы просто за 1 запрос их послать и последующие запросы не требовались. Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт). Как серию "запрос-ответ" логически объединить?
так же как любой интернет магазин.
клиент послал запрос "добавить товар в корзину"
клиент послал запрос "оформить заказ"
Есть база данных, в которой храниться состояние корзины клиента.
И есть механизм "сессия".
Каждый POST/GET запрос содержит SID (обычно в куках или как параметр в форме/урле)
Everything_is_bad,
Если авторизация обязательная, то oAuth токен и Bearer в принципе можно считать "сессией".
Так как роль идентификации пользователя решена
А так как вопрос был про фронт, то хедер заголовки пропустил. Там все же чаще AJAX, а броузер куки лепит ко всему (если не рулить этим через путь)
