Преобразование ресурсов в RESTful способ

Question

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

У меня есть два ресурса: ShadowUser и RealUser, тогда как первый имеет только имя, фамилию и адрес электронной почты. Второй пользователь имеет гораздо больше свойств, таких как идентификатор, под которым реальный пользователь может быть обращен в другом месте в системе.

My use-case это для преобразования конкретных ShadowUser s в реальных пользователей.

В моей голове поток кажется довольно простым:

• получить теневые пользователь/GET апи/ShadowUsers somePropery = SomeValue
• создавать новые реальные пользователь с данными извлекаемого/POST API/RealUsers
?
• удалить теневые пользователей/DELETE API/ShadowUSers? somePropery = SomeValue

Но что происходит, когда есть проблема между созданием новых пользователей и удаление теневых них ? Теперь данные будут непоследовательными. Пример еще проще, когда есть только один пользователь, но проблема остается такой же, как между шагами 2 и 3 может быть что-то, оставляя пользователя существующим как теневое и реальное.

Итак, вопрос в том, как это можно сделать «транзакционным» образом, когда что-то хорошее и сохраняется, или что-то пошло не так, и ничего не изменилось в базовом хранилище данных?

Есть ли какие-либо «лучшие практики» или «шаблоны дизайна», которые можно использовать?

Answer 1

Возможно, роль RESTful API GETting и POSTing настоящих пользователей в пакетном режиме (я задал вопрос несколько недель назад о связанной проблеме: Updating RESTful resources against aggregate roots only).

В стороне API пользователи POSTED не будут обрабатываться напрямую, но они будут помещены в очередь в надежной очереди сообщений (например, RabbitMQ). Фоновый процесс будет подписан на всю очередь, и он будет обрабатывать как создание, так и удаление реальных и теневых пользователей соответственно.

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

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