Блог

Приведен пример API магазина с orders ресурсом. Вы хотели бы удалить один заказ по идентификатору

УДАЛИТЬ /заказы/:Идентификатор заказа

Под капотом вы запускаете запрос на обновление и устанавливаете canceled значение true . Но что, если

• Клиент вызывает эту конечную точку:
  • Вам нужен canceledByCustomer флаг базы данных
  • Никаких дополнительных разрешений не требуется
• Администратор вызывает эту конечную точку?
  • Вам нужен rejectedByAdministrator флаг базы данных
  • Требуются дополнительные разрешения

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

Не могли бы вы добавить два параметра запроса cancel reject , и один из них ДОЛЖЕН быть true, а один из них ДОЛЖЕН быть null/false?

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

УДАЛИТЬ /заказы/:идентификатор заказа/отмена => клиент может вызвать его

УДАЛИТЬ /заказы/:идентификатор заказа/отклонить => только администраторы могут вызвать его

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

Конечные точки API не должны коррелировать с тем, что происходит ближе к ядру, например, в вашем корне Aggregate или обработчике команд. На мой взгляд, сделайте маршруты API как можно более подробными, что означает создание собственных отдельных маршрутов для каждого варианта использования. Подтолкните логику того, какой флаг базы данных использовать (canceledByCustomer против rejectedByAdministrator) ближе к сущности.