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

это не всегда возможно и сильно зависит от характера операции.

всегда можно поменять очередность действий (сначала оплата с холдом суммы потом выбор времени что бы вероятность затупов снизить).

можно разбить одну жирную операцию апдейта на много маленьких (у меня так)

Само собой. Если это условный Photoshop Online - то там нужна агрегация. Если это документы или прочие не сложные сущности - то вполне себе и можно без агрегации. Про очерёдность действий - всё верно, но это выходит за рамки рассматриваемого примера. В общем, поскольку вопрос был про REST API - моя рекомендация с учётом вводных - 1 эндпоинт с ttl, что проще и быстрее. А так как там ещё и пару человек подразумевается в юзкейсе - так и вовсе с головой будет

Вообще я изначально про нейминг чисто спрашивал, но да ладно))

Так нейминг некорректный. Причём скорее “нейминг+структура”. Но без внедрения в суть - решить её было бы сложно

Мне просто чисто ttl не подходит. Я не хочу давать условно только фикс 30 мин на изменение. А так я рад буду советам по неймингу

Между ttl и таймером - нет разницы. Потому нет смысла аппелировать к возможному значению, я лишь предлагал альтернативный механизм

А по неймингу, выглядит буд-то в системе лишь одно расписание, и по 2 эндпоинта на изменение (change) и ещё по 2 на изменение (edit). С одной стороны это должно касаться расписания, но эндпоинты только про лок вокруг сущности. Ещё одна такая сущность в системе и у вас +4 эндпоинта и всё равно на лок а не на что-то другое

Именно одно расписание и есть)

Ну вот альтернатива есть такая
/schedule/lock
/schedule/ping
/schedule/change
/schedule/no-change

Ну вернее сказать в этом сервисе

Первые 2 лишь косвенно относятся к расписанию. Потому возможно стоит рассмотреть их более глобально и добавить что-то вроде schedule-session. Вторые 2 относятся к расписанию, но можно сместить нейминг в сторону слов по типу complete.

Я бы смотрел в сторону такого списка, но это необдуманный пример

POST /schedule-session
HEAD /schedule-session
DELETE /schedule-session
PUT /schedule

А что за домен такой? Если не секрет

Имхо пришел к тому что юзать методы кроме get post - зло. Вообще подвязываться на http во многом так себе - статусы и тд

Тогда вряд-ли стоит париться по поводу REST нейминга, если не использовать его подходы

Похоже на то, что один человек зашифровывает с помощью http методов и статусов, а другой потом пытается понять что тот имел ввиду)

Я и не парился по поводу rest нейминга. Только по поводу нейминга моего апи

Кроме “REST-правил” больше никаких нет, потому если не он, то можно называть как душе угодно. Всё равно будет правильно 🤷