Да. Тот вариант правильный и более распространённый и полезный для большенство задач. Поэтому и спросил про него

Это все  делаться в бд сервиса. Ну сломался worker на 6 файле. Нечего страшного. Про  рестарте контейнера он все равно прочитает задание из бд своей и пойдёт дальше. Дойдя до 10 файла он как я думал должен кинуть в шину сообщение что все сделано на главный сервер

а еще сообщения могут быть частью других сообщений, аля колбэки :)

Так это же еще интереснее ! 🙂

всем привет, есть вопрос по структурурированию рест апи

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

1. Рест не про круд
2. Не забивай себе голову

Тебе просто нужен любой rpc

Graphql?

ок, спасибо)

спасибо) знаю о нём, собираю информацию о том что вообще есть чтобы выбрать то что лучше подойдёт

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

хороший вариант rpc

так а рест, несмотря на то что это "не про круд", не ограничивает ведь деревья обьектов

чёткие требования я не смогу перечислить, поэтому и ищу как можно больше разных вариантов организации http апи и в т.ч. в рамках реста чтобы потом выбрать самому

не ограничивает но и каких то рекомендаций не даёт, вот и ищу чем бы его таким дополнить чтобы получился контракт по апишке и неопределёнными оставались только небольшие детали

я хотел про круд вообще написать а написал про рест😁
короче, круд разве ограничивает вложеность обьектов?

с редактированием (пут/патч) понятно, с созданием то какая проблема?
например, требуется по задумке создавать заказ с позициями в корзине, сразу, отредактировать то понятно его можно будет позже, но пустая корзина вначале - это ошибка.
получается всеравно придется постить дерево обьектов - сам заказ + его корзина.
можно было бы отдельно, типа, "сначала создаем корзину, запихиваем туда позиции, потом создаем заказ и привязываем корзину и это всё n позиций + 2 запроса";
или это уже не круд (в первом случае)?

Добрый день!

Как считаете, то что enum-объект из домена используется по всему приложению - это норм?
Или на границах лучше преобразовывать?

смотри, REST условно про 3 штуки:

- идентификация ресурсов через URI - то есть для штук должен быть уникальный URI. Формат URI не важен. Может быть /users а может быть /userDetails/123?fields=first,second,third - просто для кэширования и прочего нужна уникальная идентификация
- идемпотентность - GET/PUT/DELETE должны быть идемпотентными. POST не обязан быть идемпотентным.
- гипертекст/гиперлинки - тут все проигрывают и потому у всех просто json rpc over http

правило зависимостей соблюдается