🙋Привет. Вопрос по РЕСТ шмест штукам. Как бы вы сделали: Есть

такие ресурсы
POST /process
GET /process/:id/status

POST /process/:id/sub-process
POST /process/:id/sub-process/:id/do-sth

Если эти запросы выполнять асинхронно\отдельно, проблем нет. Конкретные данные связанные с ресурсом передаешь, ничего лишнего не получаешь.
Но клиент ОЧЕНЬ хочет делать все синхронно за минимум запросов.
Например - при выполнении /sub-process/:id/do-sth нужно вернуть еще и статус /process.
В итоге все сводится к тому, что роутинг /sub-process переезжает в body метода PATCH /process/:id

PATCH /process/:id
{
"sub-process": [ {...} ]
}

Это норм вариант или есть получше?
Спасибо!

Забей на рест, делай обычный RPC (например через gRPC) и не парься

У него уже RPC У него клиенгт уже знает какие процедуры вызываются

Да я особо не заморачиваюсь с рестом, просто есть общий стиль в проекте, и все +- норм на ресурсы лягло. Но вот требования заставляют меняться))

Вроде как это хорошая практика - при создании или изменении ресурса возвращать ресурс целиком

"Клиент ОЧЕНЬ хочет делать все синхронно за минимум запросов" - это адекватное пожелание включающее в том числе уменьшение контроля на стороне клиента. Он хочет просто отправить запрос и просто получить результат, не имея большой фрагментации подпроцесов и потребности в столь высоком контроле за каждым из шагов бизнес-процеса. "Это норм вариант?" - это норм вариант. Возможно вам есть смысл разделить на несколько GET-запропосв и получать статус как по главному процессу, так и по саб-процессу, но возможно клиент захочет это иметь в виде опционального расширения в рамках одного GET, т.е. иметь GET /process/:id/status?with-sub-processes=[ids...] Как договоритесь так и будет

Я так подумал, это ведь не уменьшает контроль на стороне клиента, только в определнных случаях сокращает количество запросов и меняет роутинг вызова операция с URL на body.🤨 Клиенту в любом случае нужно выполнять эти запросы, и знать в каком случае их можно выполнять. Отличие только в том, как сформирован запрос. Возможно, контроль\знание про происходящий процесс на стороне клиента может уменьшить с помощью hypermedia.

Меньше вызовов = меньше точек отказа = меньше необходимость в контроле. Это не меняет количество точек отказа в принципе, но с точки зрения клиента - сильно упрощает интерфейс взаимодействия. Вопрос лишь в том, насколько вы можете делать это самостоятельно "на стороне сервера" и насколько можете предоставить такой интерфейс

Блин, вариант с PATCH /process/:id { "sub-process": [ {...} ] } Странно смотрится, мне нужно не просто обновить /process/:id а вызвать у sub-process определенное действие, получается переизобретение RPC POST /process/:id { "action": "do-sth-with-sub-process", "parameters": {...} } Эх, все как-то сложно с этой агрегацией ☹️

формат урлов и тип запроса к ресту постоку поскоку

Ну да)) больше интересовало как все покрасивее\удобнее вызвать и собрать в кучу

старые ручки не будут использоваться, то есть клиент полностью заменяет несколько вызово на один?

у тебя есть 2 пути: 1. смириться с тем что "то что люди называют рест" это просто json (обычно, иногда xml но уже как-то не особо встречается) rpc over http. и что от оригинального тэдиса Роя Филдинга там только то что за счет того что юзается http и uri мы тип чуть-чуть юзаем то о чем он писал но лишь совсем чуть-чуть. 2. можно воспринимать "действия" как ресурсы и тогда все по ресту) И put или post выбирать только исходя из вопроса идемпотентности (идемпотентен - берем put, нет - post). а patch не входит в спеку

Использовали оба варианта в разных проектах. Во втором варианте больше бойлерплейта надо генерить, плюс некоторые девелоперы через какое-то время скатываются к первому варианту уже для следующего левела ресурсов и тратиться время, чтобы поддерживать чёткое понимание/следование выбранной стратегии