RESTful и транзакции
занимаюсь разработкой бэкенда и пытаюсь так или иначе следовать идеям RESTful, но в процессе возникли вопросы очевидных и однозначных ответов на которые не смог найти.
При создании ресурса все просто - имеем одну конечную точку, шлем POST и создаем ресурс и все подресуры вместе с ним, ну то есть как нибудь так (в реальности сам ресурс сложнее):
{
name: 'Name',
children: [
{
name: 'Chidlren 1',
},
{
name: 'Chidlren 2',
},
]
}
Но что делать когда на стороне клиента (в данном случае UI) выполняют редактирование ресурса - это может быть удаление, создание, редактирование children. Заворачивать все эти операции в один запрос где указано что нужно удалить, обновить, и создать? Но это как-то уродливо по моему.
Или делать по очереди запросы для каждого затронутого ресурса? Но тогда что делать если ошибка произошла в процессе выполнения какого-то одного? На стороне UI будет сложно обеспечить корректную обработку данной ситуации, в идеале помогут транзакции, но они судя по всему не приняты в RESTful (потому-что необходимо храниться состояние на бэкенде, ведь речь идет о транзакции на несколько HTTP запросов). В общем если у кого-то есть опыт просьба поделиться идеями ... Спасибо!
Ответы (1 шт):
Я не про REST, а больше про концептуальное решение.
Как один из вариантов: заверните операции создания/редактирования ресурсов через очередь. Как только кто-то начал работать с ресурсом, ставьте лок на запись в таблице или просто где-то обозначайте статус «ресурс занят», чтобы не было одновременного доступа.
Процедура примерно такая:
- Получили запрос с клиентской части.
- Помещаем запрос в очередь в виде таски.
- Клиенту отвечаем «ОК, сделаем»
- Воркер просыпается, выгребает таску.
- Проверяет, стоит ли блокировка ресурса.
- Если нет, тогда ставит лок на доступ к редактированию ресурса.
- Если есть (кто-то уже работает с ним), тогда засыпает.
- Обновляет/создает ресурс.
- Снимает лок.
- Ставит таску в состояние «выполнена».
В следующий раз, когда клиент перезапросит ресурс, он вернется измененным.
В этом варианте клиент не будет блокироваться если операция создания тяжелая и длительная плюс вы будете знать, кто, сколько, когда работал с ресурсом и при необходимости сможете добавить свой вариант разрешения коллизий группируя таски по ресурсу и выкидывая одинаковые, конфликтные, неактуальные.