Как в REST хранить состояние клиента?

Question

[PerseforeComplete]

Насколько известно, REST не хранит состояние клиента между запросам.
Представьте что есть двухмерный лабиринт и есть робот, которому через REST отдают команды по перемещению по данному лабиринту. Надо довести робота из точки А в точку Б. В рамках нашей реализации это выглядит как-то так:
1. клиент отсылает путь, который робот должен пройти
2. сервер отвечает клиенту, достиг ли робот цели
3. клиент посылает команду взаимодействия с целью
3ий пункт имеет смысл только при успехе 2ого.

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

Comments

[Everything_is_bad]

не понятна в чем проблема? конечно же на сервере хранится весь путь проделанный роботом

[AlexVWill]

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

[PerseforeComplete]

Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере. Сервер отсылает результаты изменений. После чего клиент должен совершить с ними преобразование и совершить снова запрос. Из-за необходимости совершения преобразования клиентом, взаимодействие выглядит не как "клиент отправил запрос - получил ответ и все довольны", а как "клиент отправил запрос, получил ответ, снова послал запрос, ну и очевидно опять получил ответ что бы узнать о результатах". Если бы клиент располагал всеми данными, то мог бы просто за 1 запрос их послать и последующие запросы не требовались. Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт). Как серию "запрос-ответ" логически объединить?

[Everything_is_bad]

PerseforeComplete, используй сессии или подобное чтобы можно было однозначно идентифицировать клиента

Answer 1

[Олег]

так же как любой интернет магазин.
клиент послал запрос "добавить товар в корзину"
клиент послал запрос "оформить заказ"

Есть база данных, в которой храниться состояние корзины клиента.
И есть механизм "сессия".
Каждый POST/GET запрос содержит SID (обычно в куках или как параметр в форме/урле)

Comments

[Everything_is_bad]

для REST чаще в header кладут

[Олег]

Everything_is_bad,
Если авторизация обязательная, то oAuth токен и Bearer в принципе можно считать "сессией".
Так как роль идентификации пользователя решена

А так как вопрос был про фронт, то хедер заголовки пропустил. Там все же чаще AJAX, а броузер куки лепит ко всему (если не рулить этим через путь)

Answer 2

[ThunderCat]

Насколько известно, REST не хранит состояние клиента между запросам.

Это не значит что он вообще не хранит состояние клиента, это значит что он хранит только состояние на момент синхронизации, а МЕЖУ запросами состояние клиента находится в неопределенном состоянии до момента следующей синхронизации. То есть это не принцип который надо соблюдать, а констатация факта. Кроме того, в вашем примере бэкенду/апи вообще должно быть фиолетово на состояние клиента.

Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере.

Сущность лабиринт НИКАК не затрагивается, у вас может изменяться только принадлежащие вам сущности, в данном примере у вас будет меняться состояние робота.

Если бы клиент располагал всеми данными,

то он был бы бэкендом и апи было бы не нужно. Собственно апи - способ обмена запрашиваемыми данными.

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

Не лабиринт.

Как серию "запрос-ответ" логически объединить?

Зависит. Так как вопрос у вас на пальцах и вообще без конкретики, то и ответ будет достаточно общим в рамках описанной системы.
1) Вы не работаете с сущностью лабиринт, вы работаете с сущностью робот, которая имеет некоторое положение/координаты в лабиринте.
2) Сущность робот имеет уникальный идентификатор - id, по которому вы однозначно можете определить какой конкретно робот вами будет задействован. Собственно при первом запросе апи должно вам в числе прочего вернуть id робота и его положение.
3) Запрос к апи для получения позиции робота на момент следующего запроса примерно: GET someapi.tld/api/v1/robot/{id}, в результате назад вы получите объект робота с координатами. Что с ними делать зависит от вашего функционала, например можно задать новые целевые координаты.
4) Если вам нужно чтобы роботы принадлежали конкретным пользователям, вводим ключи/авторизацию, через которую апи будет определять что робот 55 принадлежит Василию Пупкину, и только он может менять координаты данного робота. Читать соответствующие мануалы.