REST - Пользовательские действия по обновлению

Question

Я работаю над REST API, и моя коллекция билетов может обновляться несколькими способами, поскольку она будет проходить через несколько состояний.Обратите внимание, что некоторые из этих состояний могут выполняться только определенной ролью (RBCA).Имея это в виду, что будет лучшим подходом?

1) Использование под-методов для конкретных действий

PATCH / tickets /: id / validate

PATCH / tickets /: id / update

PATCH / tickets /: ID / Finish

2) Управлять обновлениями на основе текущего статуса заявки и роли пользователя с помощью одного PATCH / tickets /: ID

Какой из нихлучший, когда дело доходит до лучших практик REST?

Answer 1

Какой из них лучший, когда дело доходит до лучших практик REST?

Краткий ответ: выбор № 2.

Более длинный ответ: причина, по которой мы заботимся, какаяИдентификатор используется в качестве цели запроса, так как HTTP имеет семантику аннулирования кэша, встроенную в протокол: если вы успешно исправили ресурс, задействованные общие компоненты знают, что нужно удалить все кэшированные представления этого ресурса.См. Invalidation в RFC 7234.

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

# the readable link to a specific tickets collection
/tickets/:id

# a validation form that submits data to /tickets/:id
/tickets/:id/validation

# an update form that submits data to /tickets/:id
/tickets/:id/update

# a finish form that submits data to /tickets/:id
/tickets/:id/finish

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

GET /tickets/:id
GET /tickets/:id/update
POST /tickets/:id

В API, где мы не ограничены HTML, мы могли бы рассмотреть возможность использования небезопасных методов, отличных от POST, для выполненияработа.

Примечание: это означает, что конечной точке "POST / PATCH" в нашей реализации потребуется дополнительная маршрутизация для достижения логики проверки / обновления / завершения.Для форм это будет означать использование представленных данных для определения предполагаемого поведения - возможно, скрытого поля или, возможно, конечная точка просто делает предположение, основываясь на том, какие ключи находятся в данных формы.