En mi proyecto usando la metodología DDD.

El proyecto tiene el acuerdo agregado (entidad). Este agregado tiene muchos casos de uso.

Para este agregado, necesito crear una API de descanso.

Con estándar: crear y eliminar sin problemas.

1)CreateDealUseCase(nombre, precio y muchos otros parámetros);

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

2)DeleteDealUseCase(carné de identidad)

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

¿Pero qué hacer con el resto de los casos de uso?

HoldDealUseCase (id, razón);UnholdDealUseCase (id);CompleteDealUseCase (id, y muchos otros parámetros);CancelDealUseCase (id, comercio, razón);ChangePriceUseCase (id, newPrice, reason);ChangeCompletionDateUseCase (id, newDate, amercement, whyChanged);etc (total de 20 casos de uso) ...

Cuales son las soluciones?

1)Usa verbos:

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

¡Pero! Los verbos no se pueden usar en la url (en la teoría REST).

2)Usa el estado completado(que será después del caso de uso):

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

Personalmente para mí se ve feo. ¿Puede ser que esté equivocado?

3)Utilice 1 solicitud PUT para todas las operaciones:

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

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

Es difícil de manejar en el backend. Además, es difícil de documentar. Dado que 1 acción tiene muchas variantes diferentes de solicitudes, de las cuales ya depende de respuestas específicas.

Todas las soluciones tienen inconvenientes significativos.

He leído muchos artículos sobre REST en Internet. En todas partes solo una teoría, ¿cómo estar aquí con mi problema específico?