В моем проекте используется методология DDD.

Проект имеет совокупную (юридическую) сделку. Этот агрегат имеет много вариантов использования.

Для этого агрегата мне нужно создать остальные API.

Со стандартным: создавать и удалять не проблема.

1)CreateDealUseCase(название, цена и многие другие параметры);

POST /rest/{version}/deals/
{ 
   'name': 'deal123',
   'price': 1234;
   'etc': 'etc'
}

2)DeleteDealUseCase(Я бы)

DELETE /rest/{version}/deals/{id}

Но что делать с остальными вариантами использования?

HoldDealUseCase (идентификатор, причина);UnholdDealUseCase (ID);CompleteDealUseCase (id и многие другие параметры);CancelDealUseCase (идентификатор, начало, причина);ChangePriceUseCase (id, newPrice, причина);ChangeCompletionDateUseCase (id, newDate, amercement, whyChanged);и т. д. (всего 20 вариантов использования) ...

Каковы решения?

1)Используйте глаголы:

PUT /rest/{version}/deals/{id}/hold
{ 
   'reason': 'test'
}

Но! Глаголы нельзя использовать в URL (в теории REST).

2)Используйте завершенное состояние(который будет после варианта использования):

PUT /rest/{version}/deals/{id}/holded
{ 
   'reason': 'test'
}

Лично для меня это выглядит некрасиво. Может я не прав?

3)Используйте 1 запрос PUT для всех операций:

PUT /rest/{version}/deals/{id}
{ 
   'action': 'HoldDeal',
   'params': {'reason': 'test'}
}

PUT /rest/{version}/deals/{id}
{ 
   'action': 'UnholdDeal',
   'params': {}
}

Это трудно обрабатывать в бэкэнде. Кроме того, это трудно документировать. Так как 1 действие имеет много разных вариантов запросов, от которых уже зависят конкретные ответы.

Все решения имеют существенные недостатки.

Я прочитал много статей о ОТДЫХЕ в Интернете. Везде только теория, как быть здесь с моей конкретной проблемой?